[Seaside-dev] Remaining Issues for Seaside 3.0 release

[Reza RAZAVI]

At 21:50 15/04/2010, you wrote:
>What are the exact steps that I need to follow to reproduce
>a fresh Pier image and WAFlowConvenienceFunctionalTest?

Hi Lukas, all,

I started looking at this and had some observations that I'd like to 
share with you hereafter.
I did the followings:
1) Picked http://www.seaside.st/distributions/Seaside-3.0a5.app.zip
2) Loaded from http://source.lukas-renggli.ch/pier2addons
         - Pier-Blog-lr.138
         - Pier-Setup-lr.83
3) Executed *PRDistribution new register*
4) Modified *aCommand execute* in *PRContentsWidget >> 
onAnswerCommand:* as follows:
         [(aCommand isKindOf: PRAddCommand)
                 ifTrue: [       self call: 
WAFlowConvenienceFunctionalTest new.
                                 self context command  answer: self context]
                 ifFalse: [aCommand execute] ]
                         on: Error
                         do: [ :err | ^ self component errors add: err ].

5) Pointed my browser to http://localhost:8080/pier/
6) Logged-in as admin/pier
7) Pressed the *Add* link in the Commands toolbar (to add a child to /).
8) Pressed the *Add* button in the dialog.

At this point, Seaside / Pier render *What's your favorite 
Cheese?*  etc., which is what I was expecting. The Component of 
PRContentsWidget, which is an MAContainerComponent, delegates its 
rendering to the WAFlowConvenienceFunctionalTest instance, due to the #call:.

Now, I followed visiting pages:
9) Pressed the *About* link. The default content is displayed.
10) Pressed to "Home* link. Then, WAFlowConvenienceFunctionalTest 
displays instead of the default content.
11) Refreshed the *Home* page using my browser (Chrome), 
WAFlowConvenienceFunctionalTest keeps displaying instead of the 
default content.

Since I didn't use the back button in (10) & (11), I would personally 
expect to see the default content. Otherwise, how the user could get 
ride of that component, without executing it until it *answers*, or 
creating a new session? Does that make sense?

Technically speaking, shouldn't those Delegations be released once 
the page is refreshed (at least in the case of Pier as a CMS)?

BTW, this relates to the 3rd point in my previous email on this 
topic, copied below, although not exactly the same:
         3) The user clicks on an item in the main menu (on the top), 
selected arbitrarily (the behavior that follows does not depend on 
the menu item selected). At this point, Seaside/Pier activate the 
component that was #call:'ed at the begging of the execution of the 
flow model in step (2), and was supposed to be activated during that 
stage (in place of that error message). This activated component is 
actually the first in that Sushi Store checkout process, namely *Fill 
cart*.  Once launched in this way, then the execution flows smoothly 
to the end.

It looks like the Delegation has been created, in spite of the 
*GRPharoPlatform >> seasideCallbackMarker* error message reported in 
the 2nd point of that email. I've some intuitions about the cause of 
this error. I'll share it in a post that will follow.

Regards,
Reza


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/seaside-dev/attachments/20100417/fa82ffb2/attachment.htm