From norbert at hartl.name Sun May 1 14:53:26 2011 From: norbert at hartl.name (Norbert Hartl) Date: Sun, 1 May 2011 14:53:26 +0200 Subject: Deploying few Piers - options In-Reply-To: References: Message-ID: <2FFCDCD9-2CF6-4B05-AE72-BCBF2761A724@hartl.name> Am 29.04.2011 um 16:50 schrieb Davorin Rusevljan: > Hi, > > what would be suggested path if one wants to deploy few low traffic > Piers? All Piers in one image or one image per Pier? If you are talking about low traffic this sounds like multiple kernels in one image is the easiest to do. You don't have multiple piers or pier distributions but multiple kernels that are attached two different paths via PRPierFrame. That is really easy to do and fast enough. Norbert From razavi at acm.org Sun May 1 17:46:45 2011 From: razavi at acm.org (Reza Razavi) Date: Sun, 01 May 2011 17:46:45 +0200 Subject: Deploying few Piers - options In-Reply-To: References: Message-ID: <9c0312$5543e7@smtp.pt.lu> The following would be a starting point (not tested): PRDistribution >> register: aString PRKernel reset. PRPierFrame registerAsApplication: aString kernel: self kernel PRDistribution register: 'pier1'. PRDistribution register: 'pier2'. PRDistribution register: 'pierN'. Each call to #register: (variant of exiting #register method) registers a different Pier distribution. But, as far as I remember, they share all by default the same 'files' folder. Hoping this helps, /Reza At 16:50 29/04/2011, you wrote: >Hi, > >what would be suggested path if one wants to deploy few low traffic >Piers? All Piers in one image or one image per Pier? > >Davorin Rusevljan >http://www.cloud208.com/ >_______________________________________________ >Magritte, Pier and Related Tools ... >https://www.iam.unibe.ch/mailman/listinfo/smallwiki From norbert at hartl.name Mon May 2 09:45:03 2011 From: norbert at hartl.name (Norbert Hartl) Date: Mon, 2 May 2011 09:45:03 +0200 Subject: Deploying few Piers - options In-Reply-To: <9c0312$5543e7@smtp.pt.lu> References: <9c0312$5543e7@smtp.pt.lu> Message-ID: <95FE7A41-9659-49CB-8529-7BBB74669043@hartl.name> Am 01.05.2011 um 17:46 schrieb Reza Razavi: > The following would be a starting point (not tested): > > PRDistribution >> register: aString > PRKernel reset. > PRPierFrame > registerAsApplication: aString > kernel: self kernel > > PRDistribution register: 'pier1'. > PRDistribution register: 'pier2'. > PRDistribution register: 'pierN'. > > Each call to #register: (variant of exiting #register method) registers a different Pier distribution. But, as far as I remember, they share all by default the same 'files' folder. Calling register this way is not advizable. As you can see it does 'PRKernel reset'. This will empty the instances on the PRKernel class side. You will end up having multiple kernels attached to PRPierframes as handler but only the last one will be attached to the instances of PRKernel. You're not able to e.g. select it from the configuration panel in seaside anymore. Using it without the reset is indeed a good idea. About the "files" folder. Pier uses Magritte and Magrittes MAExternalFileModel has a class side setting for the directory and path to use. So you are right, having all kernels in the same image means to share all files in the filesystem within the same directory. But I don't think this is a problem. You can easily divide them afterwards by having a visitor collecting the files for each kernel. I did this in my gemstone pier exporter utility: http://norbert.hartl.name/blog/pier-export-import-util-for-gemstone/ . Norbert > At 16:50 29/04/2011, you wrote: >> Hi, >> >> what would be suggested path if one wants to deploy few low traffic >> Piers? All Piers in one image or one image per Pier? >> >> Davorin Rusevljan >> http://www.cloud208.com/ >> _______________________________________________ >> Magritte, Pier and Related Tools ... >> https://www.iam.unibe.ch/mailman/listinfo/smallwiki > > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki From razavi at acm.org Mon May 2 10:58:26 2011 From: razavi at acm.org (Reza Razavi) Date: Mon, 02 May 2011 10:58:26 +0200 Subject: Deploying few Piers - options In-Reply-To: <95FE7A41-9659-49CB-8529-7BBB74669043@hartl.name> References: <9c0312$5543e7@smtp.pt.lu> <95FE7A41-9659-49CB-8529-7BBB74669043@hartl.name> Message-ID: <9c0312$554qie@smtp.pt.lu> Hi Norbert, I wanted just Davorin to have a pointer where to start with, and thanks for your additional precisions. So, to summarize, we have something like: PRDistribution >> register: aString PRPierFrame registerAsApplication: aString kernel: self kernel PRKernel reset. "to get ride of unwanted existing kernels" PRDistribution new register: 'pier1'. PRDistribution new register: 'pier2'. PRDistribution new register: 'pierN'. As mentioned before, I've not tested this script, since I actually use different objects (different distribution builder, kernel, and frame). Cheers, Reza From davorin.rusevljan at gmail.com Mon May 2 11:03:33 2011 From: davorin.rusevljan at gmail.com (Davorin Rusevljan) Date: Mon, 2 May 2011 11:03:33 +0200 Subject: Deploying few Piers - options In-Reply-To: <9c0312$554qie@smtp.pt.lu> References: <9c0312$5543e7@smtp.pt.lu> <95FE7A41-9659-49CB-8529-7BBB74669043@hartl.name> <9c0312$554qie@smtp.pt.lu> Message-ID: Thanks for all inputs! Are there any unexpected repercussions on persistence that I need to worry about? (I use ImageBased persistence currently) Davorin Rusevljan http://www.cloud208.com/ From norbert at hartl.name Mon May 2 11:30:55 2011 From: norbert at hartl.name (Norbert Hartl) Date: Mon, 2 May 2011 11:30:55 +0200 Subject: Deploying few Piers - options In-Reply-To: References: <9c0312$5543e7@smtp.pt.lu> <95FE7A41-9659-49CB-8529-7BBB74669043@hartl.name> <9c0312$554qie@smtp.pt.lu> Message-ID: <1A9B57EC-D002-443E-8CDF-6D7D0AB405AF@hartl.name> Am 02.05.2011 um 11:03 schrieb Davorin Rusevljan: > Thanks for all inputs! > > Are there any unexpected repercussions on persistence that I need to > worry about? (I use ImageBased persistence currently) > You need to think about your persistence strategy. A image based persistence is tied to a kernel and every write to a kernel will trigger its image based persistence. But it will save the whole image. If you have a lot of kernels than all of them might try to write the image to disk. If you have low traffic than you might have even lower writes in your pier kernel. Thus making the problem a rather theoretical one. But you might want to think of it. Norbert From razavi at acm.org Mon May 2 11:38:32 2011 From: razavi at acm.org (Reza Razavi) Date: Mon, 02 May 2011 11:38:32 +0200 Subject: Deploying few Piers - options In-Reply-To: References: <9c0312$5543e7@smtp.pt.lu> <95FE7A41-9659-49CB-8529-7BBB74669043@hartl.name> <9c0312$554qie@smtp.pt.lu> Message-ID: <2a60de$1j3lgu@smtp.pt.lu> At 11:03 02/05/2011, Davorin Rusevljan wrote: >Are there any unexpected repercussions on persistence that I need to >worry about? (I use ImageBased persistence currently) Nothing special to report, as far as I can remember now, but does not means zero risk. Basically, the (Debian) server contains: - one image and associated files, including the 'files' folder. - several virtual host configurations, one per distribution (in my configurations), which redirect http requests to the corresponding seaside/pier distribution/application. The image is automatically saved, each time one of the distributions is modified. This works technically fine, but the risk is to save your image with corrupted objects. For example, I had troubles with the search widget (on pages that contain text copied from a word document). All in all, AFAIK, this method is less frequently used for deploying Pier distributions. So, I'd recommend the follwoings: - double check some critical routines, including persistence, - configure both your server and image for a remote (emergency) access via VNC, and - backup regularly your image + files Hoping this helps, Cheers, Reza From philippe.marschall at gmail.com Tue May 3 09:01:58 2011 From: philippe.marschall at gmail.com (Philippe Marschall) Date: Tue, 3 May 2011 09:01:58 +0200 Subject: different description for "new" objects Message-ID: Hi I'm in a situation where a need a different description for newly created objects. The object itself doesn't know that it's newly created, it just know because I just created it. Answering an object and a description feels kinda kludgey so are there other options? Cheers Philippe From merlyn at stonehenge.com Tue May 3 09:17:54 2011 From: merlyn at stonehenge.com (Randal L. Schwartz) Date: Tue, 03 May 2011 00:17:54 -0700 Subject: different description for "new" objects In-Reply-To: (Philippe Marschall's message of "Tue, 3 May 2011 09:01:58 +0200") References: Message-ID: <867ha8dzh9.fsf@red.stonehenge.com> >>>>> "Philippe" == Philippe Marschall writes: Philippe> I'm in a situation where a need a different description for newly Philippe> created objects. The object itself doesn't know that it's newly Philippe> created, it just know because I just created it. Answering an object Philippe> and a description feels kinda kludgey so are there other Philippe> options? What is newly created, and when does it stop being newly created? Is it something the object should know, or the thing that created it? -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.posterous.com/ for Smalltalk discussion From norbert at hartl.name Tue May 3 09:28:40 2011 From: norbert at hartl.name (Norbert Hartl) Date: Tue, 3 May 2011 09:28:40 +0200 Subject: different description for "new" objects In-Reply-To: References: Message-ID: Am 03.05.2011 um 09:01 schrieb Philippe Marschall: > Hi > > I'm in a situation where a need a different description for newly > created objects. The object itself doesn't know that it's newly > created, it just know because I just created it. Answering an object > and a description feels kinda kludgey so are there other options? > If you don't create the objects through the usage of a description than you should be able to use the instance side description selector. As soon as you decided what is the difference between newly created and initialized (?) you can put the conditon in the instance side description selector. Norbert From philippe.marschall at gmail.com Tue May 3 10:26:50 2011 From: philippe.marschall at gmail.com (Philippe Marschall) Date: Tue, 3 May 2011 10:26:50 +0200 Subject: different description for "new" objects In-Reply-To: <867ha8dzh9.fsf@red.stonehenge.com> References: <867ha8dzh9.fsf@red.stonehenge.com> Message-ID: 2011/5/3 Randal L. Schwartz : >>>>>> "Philippe" == Philippe Marschall writes: > > Philippe> I'm in a situation where a need a different description for newly > Philippe> created objects. The object itself doesn't know that it's newly > Philippe> created, it just know because I just created it. Answering an object > Philippe> and a description feels kinda kludgey so are there other > Philippe> options? > > What is newly created, When it was created in this request (via a special service method) > and when does it stop being newly created? In the next request. > Is it > something the object should know, or the thing that created it? I'd say rather the thing that created it. Whoever the thing that created it should not have to know how it has to massage the description of the object. Cheers Philippe From sergiolist at village-buzz.com Thu May 5 06:58:21 2011 From: sergiolist at village-buzz.com (sergio_101) Date: Thu, 5 May 2011 00:58:21 -0400 Subject: forcing domain -> www.domain Message-ID: anyone have any ideas on how i might go about forcing domain.com to www.domain.com with pier? i usually do it with .htaccess, but it's doesn't work in this case.... ideas? thanks! -- ---- peace, sergio photographer, journalist, visionary http://www.CodingForHire.com http://www.coffee-black.com http://www.painlessfrugality.com http://www.twitter.com/sergio_101 http://www.facebook.com/sergio101 From renggli at gmail.com Thu May 5 10:53:11 2011 From: renggli at gmail.com (Lukas Renggli) Date: Thu, 5 May 2011 10:53:11 +0200 Subject: forcing domain -> www.domain In-Reply-To: References: Message-ID: I am using the following rewrite rules: # fix hostname RewriteCond %{HTTP_HOST} !^www\.lukas-renggli\.ch [nocase] RewriteCond %{HTTP_HOST} !^$ RewriteRule ^/(.*) http://www.lukas-renggli.ch/$1 [redirect,last] Lukas On 5 May 2011 06:58, sergio_101 wrote: > anyone have any ideas on how i might go about forcing > > domain.com > > to > > www.domain.com > > with pier? > > i usually do it with .htaccess, but it's doesn't work in this case.... > > ideas? > > thanks! > > -- > ---- > peace, > sergio > photographer, journalist, visionary > > http://www.CodingForHire.com > http://www.coffee-black.com > http://www.painlessfrugality.com > http://www.twitter.com/sergio_101 > http://www.facebook.com/sergio101 > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > -- Lukas Renggli www.lukas-renggli.ch From chaetal at gmail.com Thu May 5 21:58:37 2011 From: chaetal at gmail.com (Dennis Schetinin) Date: Thu, 5 May 2011 23:58:37 +0400 Subject: Shorter URLs on seasidehosting.st Message-ID: Trying to set up a site at chaetal.seasidehosting.st and provide "shorter" URLs (like http://chaetal.seasidehosting.st/about instead of http://chaetal.seasidehosting.st/pier/about) there I've encountered a problem. All the tutorials, manuals, FAQs I found say something like "select your preferred application as default entry point and set the base-path of your application to "/". I do that but Seaside says (for example) "/seaside/about/ not found" when I click "About". I don't remember how we solved this in earlier versions of Seaside and Pier. And I'm not sure about who is actually responsible for this: Pier, Seaside or hosting? But I don't see any opportunities at seasidehosting to do what I want at web-server level. So, how can I do that with Seaside or/and Pier? TIA -- Dennis Schetinin From nick.ager at gmail.com Fri May 6 00:45:28 2011 From: nick.ager at gmail.com (Nick Ager) Date: Thu, 5 May 2011 23:45:28 +0100 Subject: Shorter URLs on seasidehosting.st In-Reply-To: References: Message-ID: Hi Dennis, I've written a blog article about various options for removing the application name from the URL: http://nickager.com/blog/serving-seaside-requests-without-the-application-name-in-the-URL/ I haven't tried this on seasidehosting.st but I think the ideas should work. Hope this helps Nick -------------- next part -------------- An HTML attachment was scrubbed... URL: From davorin.rusevljan at gmail.com Thu May 12 12:26:46 2011 From: davorin.rusevljan at gmail.com (Davorin Rusevljan) Date: Thu, 12 May 2011 12:26:46 +0200 Subject: OS Prerequisites for Pier Book Message-ID: Hello, what are the operatin system, and installed packages prerequisites for Pier Book? What needs to be installed? Davorin Rusevljan http://www.cloud208.com/ From renggli at gmail.com Thu May 12 19:22:54 2011 From: renggli at gmail.com (Lukas Renggli) Date: Thu, 12 May 2011 19:22:54 +0200 Subject: OS Prerequisites for Pier Book In-Reply-To: References: Message-ID: Take the one-click image from the website. It has all code loaded and works on Linux, Mac and Windows. Alternatively you could use the Pier2Configuration and load just what depends on the Pier-Book package. This works anywhere where Pharo runs (e.g. on the iPhone). There are no other dependencies, unless you want to generate a PDF what requires a working LaTeX installation. Cheers, Lukas On Thursday, 12 May 2011, Davorin Rusevljan wrote: > Hello, > > what are the operatin system, and installed packages prerequisites for > Pier Book? What needs to be installed? > > Davorin Rusevljan > http://www.cloud208.com/ > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > -- Lukas Renggli www.lukas-renggli.ch From davorin.rusevljan at gmail.com Thu May 12 21:11:22 2011 From: davorin.rusevljan at gmail.com (Davorin Rusevljan) Date: Thu, 12 May 2011 21:11:22 +0200 Subject: OS Prerequisites for Pier Book In-Reply-To: References: Message-ID: Yes I was refering to one click image and what it needs from os to work like pdf generation for instance. Thanks! Davorin On May 12, 2011 7:25 PM, "Lukas Renggli" wrote: Take the one-click image from the website. It has all code loaded and works on Linux, Mac and Windows. Alternatively you could use the Pier2Configuration and load just what depends on the Pier-Book package. This works anywhere where Pharo runs (e.g. on the iPhone). There are no other dependencies, unless you want to generate a PDF what requires a working LaTeX installation. Cheers, Lukas On Thursday, 12 May 2011, Davorin Rusevljan wrote: > Hello, > > what ... > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > -- Lukas Renggli www.lukas-renggli.ch _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick.ager at gmail.com Wed May 18 16:33:34 2011 From: nick.ager at gmail.com (Nick Ager) Date: Wed, 18 May 2011 15:33:34 +0100 Subject: sessions, continuation keys, restful urls and component state Message-ID: Hi, I've noticed a problem with cookies enabled and Pier. The problem arises when you browse to a URL without the continuation key, which causes a new instance of the application to be created ie PRPierFrame new. You can see the issue with the following single page WACounter Pier app: | rootPage | rootPage := (PRPage named: 'rootPage') contents: '+counter+'; yourself. rootPage localEnvironment: ((PRComponent named: 'contents') componentClass: PRContentsWidget; yourself). rootPage addChild: ((PRComponent named: 'counter') componentClass: WACounter; yourself). PRKernel reset. (PRPierFrame registerAsApplication: 'pier' kernel: (PRKernel named: 'testKernel' root: rootPage)) preferenceAt: #useCookies put: true. Browse to localhost:xxxx/pier you should see the familiar counter component. Increment the counter a few times. Now open a new tab, browse to localhost:xxxx/pier and decrement the counter a couple of times. Return to the first tab and try incrementing again. The counter will increment from the value of the second counter. I tested the same code snippet in Pier 1 on Seaside 2.8 and the component increments from the value on the page ie it behaves as you'd expect a Seaside component to behave. The problem appears to arise in: WASession>>#handleFiltered: aRequestContext | key continuation | key := aRequestContext request fields at: self actionField ifAbsent: [ ^ self start ]. continuation := continuations at: key ifAbsent: [ ^ self unknownRequest ]. continuation value if there is no continuation key, #start is called on the session, which creates a new root component. I have a fix, though it's in such a core part of Seaside, I'm hesitant to suggest it. If I change WARenderLoopMain>>#start from: start | root | root := self createRoot. self session properties at: #presenter put: root. self prepareRoot: root. ((self application preferenceAt: #renderPhaseContinuationClass) new) > captureAndInvoke to: start | root | root := self session presenter. root ifNil: [ root := self createRoot. self session properties at: #presenter put: root. self prepareRoot: root ]. ((self application preferenceAt: #renderPhaseContinuationClass) new) > captureAndInvoke ...the root component is recovered from the session (if present) and no longer created. Is this a valid fix? Thanks Nick -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick.ager at gmail.com Wed May 18 17:22:48 2011 From: nick.ager at gmail.com (Nick Ager) Date: Wed, 18 May 2011 16:22:48 +0100 Subject: PRPierFrame>>#notFound and images Message-ID: Hi, I had a component in Pier which included in a rendering message: html div class: 'grey_copy14'; style: 'background-image:url(img/faq_title.gif);' If you can ignore my poor style with inline css, when 'img/faq_title.gif' wasn't present, PRPierFrame>>#notFound is called. This then caused a new component to be created and my context to be reset (see my previous post "sessions, continuation keys, restful urls and component state") Even if we fix the new component creation but it still seems unnecessary that for images #notFound resets the structure and view: notFound "This method is called whenever the current request cannot be resolved to a > structure." self context: (self context structure: self context root view: PRNotFoundView) I propose a fix to only redirect if the MimeType is non-binary, something along the lines of notFound "This method is called whenever the current request cannot be resolved to a > structure." self requestContext request mimeType isBinary ifTrue: [ self requestContext > responseGenerator notFound ] self context: (self context structure: self context root view: PRNotFoundView) Assuming others think this is a reasonable idea, a problem arises in that WARequest doesn't implement #mimeType. I'd propose refactoring WAExternalFileLibrary>>#mimetypeForRequest: and WAFileLibrary>>#mimetypeFor: Does that seem a reasonable course of action? Nick -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick.ager at gmail.com Wed May 18 20:03:43 2011 From: nick.ager at gmail.com (Nick Ager) Date: Wed, 18 May 2011 19:03:43 +0100 Subject: PRPierFrame>>#notFound and images In-Reply-To: References: Message-ID: The change doesn't require the "random refactoring" I feared. Assuming others think this is a reasonable idea, a problem arises in that > WARequest doesn't implement #mimeType. I'd propose > refactoring WAExternalFileLibrary>>#mimetypeForRequest: and > WAFileLibrary>>#mimetypeFor: > > Does that seem a reasonable course of action? > Instead I implement PRPierFrame>>#isFileRequest | path | path := self requestContext request url path. ^ (path notEmpty and: [ path last includes: $. ]) and modify PRPierFrame>>#notFound to read: notFound "This method is called whenever the current request cannot be resolved to a structure." self isFileRequest ifTrue: [ self requestContext respond: [: response | response notFound ] ]. self context: (self context structure: self context root view: IZNotFoundView) Anyone think this is a bad idea? If not I'll check it in. -------------- next part -------------- An HTML attachment was scrubbed... URL: From renggli at gmail.com Wed May 18 22:59:48 2011 From: renggli at gmail.com (Lukas Renggli) Date: Wed, 18 May 2011 22:59:48 +0200 Subject: PRPierFrame>>#notFound and images In-Reply-To: References: Message-ID: Hi Nick, I don't like the solution that looks for the $. It assumes that there are only dots in resources (which is not necessarily the case). Why don't you create the image in your component through a correct context? Something along ... html image src: (self context structure: aImageResource) url Not sure if I recall the exact API. Lukas On 18 May 2011 20:03, Nick Ager wrote: > The change doesn't require the "random refactoring" I feared. >> >> Assuming others think this is a reasonable idea, a problem arises in that >> WARequest doesn't implement #mimeType. I'd propose >> refactoring?WAExternalFileLibrary>>#mimetypeForRequest: and >> WAFileLibrary>>#mimetypeFor: >> Does that seem a reasonable course of action? > > Instead I implement > PRPierFrame>>#isFileRequest > | path | > path := self requestContext request url path. > ^ (path notEmpty and: [ path last includes: $. ]) > and modify PRPierFrame>>#notFound to read: > notFound > "This method is called whenever the current request cannot be resolved to a > structure." > self isFileRequest ifTrue: [ self requestContext respond: [: response | > response notFound ] ]. > self context: (self context > structure: self context root > view: IZNotFoundView) > > Anyone think this is a bad idea? If not I'll check it in. > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > -- Lukas Renggli www.lukas-renggli.ch From nick.ager at gmail.com Wed May 18 23:15:59 2011 From: nick.ager at gmail.com (Nick Ager) Date: Wed, 18 May 2011 22:15:59 +0100 Subject: sessions, continuation keys, restful urls and component state In-Reply-To: References: Message-ID: >From Julian: I'm sure if this is relevant anymore but it's what I was writing before we talked. Feel free to forward to the list if you think it's relevant/helpful/interesting/whatever. Julian --------------- I'm not sure it's a good fix in the general case. If you don't have a continuation key, you shouldn't (by definition) have any existing (backtracked) state. Relying on the root presenter currently in the Session is problematic since that value is backtracked for each request; you'll simply get whichever root happened to be used by whatever request was last handled by that session. If you don't happen to be ever changing the root, then it may well be what you want, but it's not right in the general case. Incidentally, this also touches on the flaw I was discussing the other week with our snapshots: because we have no continuation key, we really ought to nil out any backtracked data before processing the request (at least that way we have a consistent state while handling the request). We don't run into the problem with the root presenter because #start reinitializes it, but for other backtracked state, you'd just get random stuff in there based on the last-handled request. A more appropriate general fix (at least in this case) could be to take the last-used continuation and apply its state before handling a request with no _k. However, we don't always know the last-used (depending on the caching mechanism in place) and I'm not convinced that is actually always what people want. I still feel pretty confident that the "right" semantics of an Application/Session request with no _k is to start a new main/render-loop. On 18 May 2011 15:33, Nick Ager wrote: > Hi, > > I've noticed a problem with cookies enabled and Pier. The problem arises > when you browse to a URL without the continuation key, which causes a new > instance of the application to be created ie PRPierFrame new. You can see > the issue with the following single page WACounter Pier app: > > > | rootPage | > > rootPage := (PRPage named: 'rootPage') contents: '+counter+'; yourself. > rootPage localEnvironment: ((PRComponent named: 'contents') > componentClass: PRContentsWidget; yourself). > rootPage addChild: ((PRComponent named: 'counter') componentClass: > WACounter; yourself). > > PRKernel reset. > (PRPierFrame registerAsApplication: 'pier' kernel: (PRKernel named: > 'testKernel' root: rootPage)) preferenceAt: #useCookies put: true. > > > Browse to localhost:xxxx/pier you should see the familiar counter > component. Increment the counter a few times. Now open a new tab, browse > to localhost:xxxx/pier and decrement the counter a couple of times. Return > to the first tab and try incrementing again. The counter will increment from > the value of the second counter. > I tested the same code snippet in Pier 1 on Seaside 2.8 and the component > increments from the value on the page ie it behaves as you'd expect a > Seaside component to behave. > > The problem appears to arise in: > > WASession>>#handleFiltered: aRequestContext > > | key continuation | > > key := aRequestContext request fields > > at: self actionField > > ifAbsent: [ ^ self start ]. > > continuation := continuations > > at: key > > ifAbsent: [ ^ self unknownRequest ]. > > continuation value > > > if there is no continuation key, #start is called on the session, which > creates a new root component. I have a fix, though it's in such a core part > of Seaside, I'm hesitant to suggest it. If I change WARenderLoopMain>>#start > from: > > start > > | root | > > root := self createRoot. > > self session properties at: #presenter put: root. > > self prepareRoot: root. > > ((self application preferenceAt: #renderPhaseContinuationClass) new) >> captureAndInvoke > > > to: > > start > > | root | > > root := self session presenter. > > root ifNil: [ > > root := self createRoot. > > self session properties at: #presenter put: root. > > self prepareRoot: root ]. > > ((self application preferenceAt: #renderPhaseContinuationClass) new) >> captureAndInvoke > > > ...the root component is recovered from the session (if present) and no > longer created. > > Is this a valid fix? > > Thanks > > Nick > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergiolist at village-buzz.com Mon May 23 06:21:21 2011 From: sergiolist at village-buzz.com (sergio_101) Date: Mon, 23 May 2011 00:21:21 -0400 Subject: cannot upload images.. Message-ID: i have a new image that i am trying to upload images to.. for some reason, i keep getting: The requested object /pier/90/kk960ph0xzfwmlp31li9l3hwmgsbt4/unknown was not found on this server. everything in the setup looks okay, and i can add and delete pages at will.. i just can't upload files.. any ideas? thanks! -- ---- peace, sergio photographer, journalist, visionary http://www.CodingForHire.com http://www.coffee-black.com http://www.painlessfrugality.com http://www.twitter.com/sergio_101 http://www.facebook.com/sergio101 From tudor at tudorgirba.com Mon May 23 14:45:39 2011 From: tudor at tudorgirba.com (Tudor Girba) Date: Mon, 23 May 2011 14:45:39 +0200 Subject: value links in the latest pier Message-ID: Hi, I am slowly migrating to Pier2 and I stumbled across a slight difference in the way value links work. In particular, I have the following issues: - +>value:structure+ used to display the title of the current structure, but now it embeds the complete structure. I played with different variations of specifying a title attribute (e.g., +value:structure|title+) but it did not work - +value:children|link+ used to display a link to all the children, but now it simply embeds all children I tried to debug these issues, but I did not manage to understand what is wrong. Am I using it in an obsolete way, or is this a bug? Cheers, Doru -- www.tudorgirba.com "Yesterday is a fact. Tomorrow is a possibility. Today is a challenge." From norbert at hartl.name Mon May 23 15:23:35 2011 From: norbert at hartl.name (Norbert Hartl) Date: Mon, 23 May 2011 15:23:35 +0200 Subject: value links in the latest pier In-Reply-To: References: Message-ID: <946671F7-41FB-49E4-A389-A28CFF2B82F4@hartl.name> Am 23.05.2011 um 14:45 schrieb Tudor Girba: > Hi, > > I am slowly migrating to Pier2 and I stumbled across a slight difference in the way value links work. In particular, I have the following issues: > > - +>value:structure+ used to display the title of the current structure, but now it embeds the complete structure. I played with different variations of specifying a title attribute (e.g., +value:structure|title+) but it did not work > - +value:children|link+ used to display a link to all the children, but now it simply embeds all children > > I tried to debug these issues, but I did not manage to understand what is wrong. Am I using it in an obsolete way, or is this a bug? > The answer is just to obvious to be found :) Try exchanging + with * which is linked instead of embedded. Norbert From razavi at acm.org Mon May 23 15:44:40 2011 From: razavi at acm.org (Reza Razavi) Date: Mon, 23 May 2011 15:44:40 +0200 Subject: value links in the latest pier In-Reply-To: References: Message-ID: <9c0312$596d6s@smtp.pt.lu> Doru, I'm using those value links in my distributions. They behave as expected in both cases. Reza At 14:45 23/05/2011, Tudor Girba wrote: >Hi, > >I am slowly migrating to Pier2 and I stumbled across a slight >difference in the way value links work. In particular, I have the >following issues: > >- +>value:structure+ used to display the title of the current >structure, but now it embeds the complete structure. I played with >different variations of specifying a title attribute (e.g., >+value:structure|title+) but it did not work >- +value:children|link+ used to display a link to all the children, >but now it simply embeds all children > >I tried to debug these issues, but I did not manage to understand >what is wrong. Am I using it in an obsolete way, or is this a bug? > >Cheers, >Doru > > >-- >www.tudorgirba.com > >"Yesterday is a fact. > Tomorrow is a possibility. > Today is a challenge." > > > > >_______________________________________________ >Magritte, Pier and Related Tools ... >https://www.iam.unibe.ch/mailman/listinfo/smallwiki From tudor at tudorgirba.com Mon May 23 22:09:59 2011 From: tudor at tudorgirba.com (Tudor Girba) Date: Mon, 23 May 2011 22:09:59 +0200 Subject: value links in the latest pier In-Reply-To: <946671F7-41FB-49E4-A389-A28CFF2B82F4@hartl.name> References: <946671F7-41FB-49E4-A389-A28CFF2B82F4@hartl.name> Message-ID: Hi, Thanks :). Indeed, it works. Does that mean that basically value links work only with * from now on? Cheers, Doru On 23 May 2011, at 15:23, Norbert Hartl wrote: > > Am 23.05.2011 um 14:45 schrieb Tudor Girba: > >> Hi, >> >> I am slowly migrating to Pier2 and I stumbled across a slight difference in the way value links work. In particular, I have the following issues: >> >> - +>value:structure+ used to display the title of the current structure, but now it embeds the complete structure. I played with different variations of specifying a title attribute (e.g., +value:structure|title+) but it did not work >> - +value:children|link+ used to display a link to all the children, but now it simply embeds all children >> >> I tried to debug these issues, but I did not manage to understand what is wrong. Am I using it in an obsolete way, or is this a bug? >> > The answer is just to obvious to be found :) > > Try exchanging + with * which is linked instead of embedded. > > Norbert > > > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki -- www.tudorgirba.com "We cannot reach the flow of things unless we let go." From renggli at gmail.com Mon May 23 22:19:30 2011 From: renggli at gmail.com (Lukas Renggli) Date: Mon, 23 May 2011 22:19:30 +0200 Subject: value links in the latest pier In-Reply-To: References: <946671F7-41FB-49E4-A389-A28CFF2B82F4@hartl.name> Message-ID: No, value links work with * and with + now, and do what other links do too. We implemented that together last time we worked on Pier at your place :-) Lukas On 23 May 2011 22:09, Tudor Girba wrote: > Hi, > > Thanks :). Indeed, it works. > > Does that mean that basically value links work only with * from now on? > > Cheers, > Doru > > > On 23 May 2011, at 15:23, Norbert Hartl wrote: > >> >> Am 23.05.2011 um 14:45 schrieb Tudor Girba: >> >>> Hi, >>> >>> I am slowly migrating to Pier2 and I stumbled across a slight difference in the way value links work. In particular, I have the following issues: >>> >>> - +>value:structure+ used to display the title of the current structure, but now it embeds the complete structure. I played with different variations of specifying a title attribute (e.g., +value:structure|title+) but it did not work >>> - +value:children|link+ used to display a link to all the children, but now it simply embeds all children >>> >>> I tried to debug these issues, but I did not manage to understand what is wrong. Am I using it in an obsolete way, or is this a bug? >>> >> The answer is just to obvious to be found :) >> >> Try exchanging + with * which is linked instead of embedded. >> >> Norbert >> >> >> _______________________________________________ >> Magritte, Pier and Related Tools ... >> https://www.iam.unibe.ch/mailman/listinfo/smallwiki > > -- > www.tudorgirba.com > > "We cannot reach the flow of things unless we let go." > > > > > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > -- Lukas Renggli www.lukas-renggli.ch From tudor at tudorgirba.com Tue May 24 16:35:12 2011 From: tudor at tudorgirba.com (Tudor Girba) Date: Tue, 24 May 2011 16:35:12 +0200 Subject: value links in the latest pier In-Reply-To: References: <946671F7-41FB-49E4-A389-A28CFF2B82F4@hartl.name> Message-ID: <4498802C-69D1-4310-BE81-CDEA3EF33817@tudorgirba.com> Hi, This is what I remembered as well. But, the thing is that + does not seem to work anymore with parameters. Cheers, Doru On 23 May 2011, at 22:19, Lukas Renggli wrote: > No, value links work with * and with + now, and do what other links do > too. We implemented that together last time we worked on Pier at your > place :-) > > Lukas > > On 23 May 2011 22:09, Tudor Girba wrote: >> Hi, >> >> Thanks :). Indeed, it works. >> >> Does that mean that basically value links work only with * from now on? >> >> Cheers, >> Doru >> >> >> On 23 May 2011, at 15:23, Norbert Hartl wrote: >> >>> >>> Am 23.05.2011 um 14:45 schrieb Tudor Girba: >>> >>>> Hi, >>>> >>>> I am slowly migrating to Pier2 and I stumbled across a slight difference in the way value links work. In particular, I have the following issues: >>>> >>>> - +>value:structure+ used to display the title of the current structure, but now it embeds the complete structure. I played with different variations of specifying a title attribute (e.g., +value:structure|title+) but it did not work >>>> - +value:children|link+ used to display a link to all the children, but now it simply embeds all children >>>> >>>> I tried to debug these issues, but I did not manage to understand what is wrong. Am I using it in an obsolete way, or is this a bug? >>>> >>> The answer is just to obvious to be found :) >>> >>> Try exchanging + with * which is linked instead of embedded. >>> >>> Norbert >>> >>> >>> _______________________________________________ >>> Magritte, Pier and Related Tools ... >>> https://www.iam.unibe.ch/mailman/listinfo/smallwiki >> >> -- >> www.tudorgirba.com >> >> "We cannot reach the flow of things unless we let go." >> >> >> >> >> _______________________________________________ >> Magritte, Pier and Related Tools ... >> https://www.iam.unibe.ch/mailman/listinfo/smallwiki >> > > > > -- > Lukas Renggli > www.lukas-renggli.ch > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki -- www.tudorgirba.com "We cannot reach the flow of things unless we let go." From tudor at tudorgirba.com Fri May 27 11:53:07 2011 From: tudor at tudorgirba.com (Tudor Girba) Date: Fri, 27 May 2011 11:53:07 +0200 Subject: jquery-based slideshow? Message-ID: <3A4EAEB7-2A87-4B54-8796-3E1ACF76A26C@tudorgirba.com> Hi, Has anyone produced a JQuery-based slideshow for Pier 2? Cheers, Doru -- www.tudorgirba.com "What we can governs what we wish." From razavi at acm.org Fri May 27 12:22:01 2011 From: razavi at acm.org (Reza Razavi) Date: Fri, 27 May 2011 12:22:01 +0200 Subject: jquery-based slideshow? In-Reply-To: <3A4EAEB7-2A87-4B54-8796-3E1ACF76A26C@tudorgirba.com> References: <3A4EAEB7-2A87-4B54-8796-3E1ACF76A26C@tudorgirba.com> Message-ID: Doru, For his photos, my son has found the following solution: 1) Uses Flickr.com for storing his photos, and 2) Creates a "simple" page with the content reproduced bellow (where references to "FIXME" should be replaced by individual information) Here is an example: http://www.rezarazavi.com/goya/ I've not tested it, but maybe it (or a variant) could also be used as a practical slideshow solution?! Hoping this helps, Reza {{{
}}} *Goya Razavi>http://www.goyarazavi.com* At 11:53 27/05/2011, you wrote: >Hi, > >Has anyone produced a JQuery-based slideshow for Pier 2? > >Cheers, >Doru > >-- >www.tudorgirba.com > >"What we can governs what we wish." > > > >_______________________________________________ >Magritte, Pier and Related Tools ... >https://www.iam.unibe.ch/mailman/listinfo/smallwiki -------------- next part -------------- An HTML attachment was scrubbed... URL: From tudor at tudorgirba.com Fri May 27 12:36:50 2011 From: tudor at tudorgirba.com (Tudor Girba) Date: Fri, 27 May 2011 12:36:50 +0200 Subject: jquery-based slideshow? In-Reply-To: References: <3A4EAEB7-2A87-4B54-8796-3E1ACF76A26C@tudorgirba.com> Message-ID: <9D0CF981-EB9D-443D-8DCD-C2D49140D449@tudorgirba.com> Thanks. However, I am looking for a solution that controls the look, it is applicable to any structure, and keeps the user on site. Cheers, Doru On 27 May 2011, at 12:22, Reza Razavi wrote: > Doru, > > For his photos, my son has found the following solution: > 1) Uses Flickr.com for storing his photos, and > 2) Creates a "simple" page with the content reproduced bellow (where references to "FIXME" should be replaced by individual information) > > Here is an example: > http://www.rezarazavi.com/goya/ > > I've not tested it, but maybe it (or a variant) could also be used as a practical slideshow solution?! > Hoping this helps, > Reza > > {{{
> >
}}} > *Goya Razavi>http://www.goyarazavi.com* > > At 11:53 27/05/2011, you wrote: >> Hi, >> >> Has anyone produced a JQuery-based slideshow for Pier 2? >> >> Cheers, >> Doru >> >> -- >> www.tudorgirba.com >> >> "What we can governs what we wish." >> >> >> >> _______________________________________________ >> Magritte, Pier and Related Tools ... >> https://www.iam.unibe.ch/mailman/listinfo/smallwiki > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki -- www.tudorgirba.com "Being happy is a matter of choice." From nick.ager at gmail.com Fri May 27 12:54:18 2011 From: nick.ager at gmail.com (Nick Ager) Date: Fri, 27 May 2011 11:54:18 +0100 Subject: jquery-based slideshow? In-Reply-To: <3A4EAEB7-2A87-4B54-8796-3E1ACF76A26C@tudorgirba.com> References: <3A4EAEB7-2A87-4B54-8796-3E1ACF76A26C@tudorgirba.com> Message-ID: I don't know of anything specifically for Pier though I integrated the JQuery cycle (http://jquery.malsup.com/cycle/): ((Smalltalk at: #ConfigurationOfJQueryWidgetBox) project latestVersion) load: #('JQWidgetBox-Core' 'JQWidgetBox-Dev' 'JQWidgetBox-Cycle-Core' 'JQWidgetBox-Cycle-Dev') On 27 May 2011 10:53, Tudor Girba wrote: > Hi, > > Has anyone produced a JQuery-based slideshow for Pier 2? > > Cheers, > Doru > > -- > www.tudorgirba.com > > "What we can governs what we wish." > > > > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > -------------- next part -------------- An HTML attachment was scrubbed... URL: From razavi at acm.org Fri May 27 13:09:44 2011 From: razavi at acm.org (Reza Razavi) Date: Fri, 27 May 2011 13:09:44 +0200 Subject: jquery-based slideshow? In-Reply-To: <9D0CF981-EB9D-443D-8DCD-C2D49140D449@tudorgirba.com> References: <3A4EAEB7-2A87-4B54-8796-3E1ACF76A26C@tudorgirba.com> <9D0CF981-EB9D-443D-8DCD-C2D49140D449@tudorgirba.com> Message-ID: I use in a Pier2 image, the PRSlideshow package from Pier1. Here are a few examples: http://www.aas-platform.com/about/doc/slideslist/ I've a few patches that are attached (not sure if they are mandatory fro the Pier1 package to work with Pier2, and as far as I remember, they are mostly copied from PRSlideshowCrossFade). Also, I've a specialized distribution builder that loads the slides at build time. The scripts are provided below. Hoping this helps, Reza slideWidget slidesWidget ifNotNil: [^slidesWidget]. slidesWidget := self defaultSlideShowWidgetNamed: 'slides'. self addPresentationSlidesTo: slidesWidget from: self defaultSlideShowDir total: self defaultSlideShowSize. ^slidesWidget defaultSlideShowWidgetNamed: aString | aWidget | aWidget := PRComponent named: aString. aWidget title: PRSlideshow label; componentClass: PRSlideshow. aWidget write: true using: PRSlideshow descriptionSlideList; write: true using: PRSlideshow descriptionSlideNumber. ^aWidget addPresentationSlidesTo: aSlidesWidget from: dirS total: aNumber | prefixS suffixS coef fileS fn n t sPage w h contentF p | prefixS := 'Diapositive'. suffixS := '.png'. GRPlatform current isUnix ifTrue: [suffixS := suffixS asUppercase]. coef := "0.8" 1. 1 to: aNumber do: [:i | fileS := dirS, FileDirectory slash, (fn := (prefixS, i printString), suffixS). t := prefixS, ' ', i printString. n := "prefixS" 'slide-', i printString. sPage := PRPage named: n. sPage title: t. w := (768 * coef) printString. h := (576 * coef) printString. sPage contents: ('+', n, '|width=', w, '|height=', h, '+'). contentF := GRPlatform current contentsOfFile: fileS binary: true. p := PRFile named: n. p title: 'Slide ', i printString. p filename: fn; title: t; mimetype: 'image/png'; contents: contentF. aSlidesWidget addChild: sPage. sPage addChild: p]. At 12:36 27/05/2011, Tudor Girba wrote: >Thanks. > >However, I am looking for a solution that controls the look, it is >applicable to any structure, and keeps the user on site. > >Cheers, >Doru > > >On 27 May 2011, at 12:22, Reza Razavi wrote: > > > Doru, > > > > For his photos, my son has found the following solution: > > 1) Uses Flickr.com for storing his photos, and > > 2) Creates a "simple" page with the content reproduced bellow > (where references to "FIXME" should be replaced by individual information) > > > > Here is an example: > > http://www.rezarazavi.com/goya/ > > > > I've not tested it, but maybe it (or a variant) could also be > used as a practical slideshow solution?! > > Hoping this helps, > > Reza > > > > {{{
> > value="offsite=true&lang=en-us&page_show_url=%2Fphotos%2Fgoyarazavi%2Fshow%2F&page_show_back_url=%2Fphotos%2Fgoyarazavi%2F&user_id=FIXME&jump_to="> > value="http://www.flickr.com/apps/slideshow/show.swf?v=FIXME"> > type="application/x-shockwave-flash" > src="http://www.flickr.com/apps/slideshow/show.swf?v=FIXME" > allowFullScreen="true" > flashvars="offsite=true&lang=en-us&page_show_url=%2Fphotos%2Fgoyarazavi%2Fshow%2F&page_show_back_url=%2Fphotos%2Fgoyarazavi%2F&user_id=FIXME&jump_to=" > width="700" height="525"> > >
}}} > > *Goya Razavi>http://www.goyarazavi.com* > > > > At 11:53 27/05/2011, you wrote: > >> Hi, > >> > >> Has anyone produced a JQuery-based slideshow for Pier 2? > >> > >> Cheers, > >> Doru > >> > >> -- > >> www.tudorgirba.com > >> > >> "What we can governs what we wish." > >> > >> > >> > >> _______________________________________________ > >> Magritte, Pier and Related Tools ... > >> https://www.iam.unibe.ch/mailman/listinfo/smallwiki > > _______________________________________________ > > Magritte, Pier and Related Tools ... > > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > >-- >www.tudorgirba.com > >"Being happy is a matter of choice." > > > > >_______________________________________________ >Magritte, Pier and Related Tools ... >https://www.iam.unibe.ch/mailman/listinfo/smallwiki -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: PRSlideshow-#AAS.lu-Pier.st Type: application/octet-stream Size: 2192 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: PRSlideshow class-#AAS.lu-Pier.st Type: application/octet-stream Size: 1006 bytes Desc: not available URL: