[Seaside-dev] Remaining Issues for Seaside 3.0 release

[Reza RAZAVI]

At 14:09 15/04/2010, you wrote:
>1) The current page renders an internal link to a (Pier) context 
>that when activated triggers the execution of a flow model. This is 
>comparable to the links that appear in Pier's toolbars, like Add, Edit, etc.
>2) The user clicks on that link. The context is activated, the 
>execution of the flow model is launched, which yields to a #call:. 
>At this point, GRPharoPlatform >> seasideCallbackMarker raises its 
>exception, which is catched by PRContentsWidget >> onAnswerCommand:, 
>and rendered by Pier as the result of the execution. The execution 
>stops there, although the flow model corresponds actually to the 
>Sushi Store checkout process, as implemented by Seaside, and 
>documented here [2]. So, the user was rather expecting to go through 
>the Fill Cart / Confirm Content iteration.

The execution of Pier Commands is triggered by *PRContentsWidget >> 
onAnswerCommand:*. Most Pier Commands need to render a dialog box, 
before getting executed. They respond *false* to #isQuick. There are 
few exeception like logout Command.

When a Command isQuick, *PRContentsWidget >> onAnswerCommand:* is 
called by *PRContentsWidget >> onChangeContext:*, which in turn is 
called as follows:
- PRPierFrame >> update
- WAActionPhaseContinuation >> runCallbacks
- WAActionPhaseContinuation >> handleRequest

In the above execution context, WACallbacks are not involved, which 
may explain the error message in *GRPharoPlatform >> 
seasideCallbackMarker*. (WACallbacks get typically involved in the 
second part of the processings in *WAActionPhaseContinuation >> 
handleRequest*, that is WAActionPhaseContinuation >> continue)

Should I conclude that Seaside Components shall not be #calle:'ed in 
the above frame?

Regards,
Reza