[Seaside-dev] Remaining Issues for Seaside 3.0 release
Reza RAZAVI
razavi at acm.org
Sat Apr 17 08:41:09 UTC 2010
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
More information about the seaside-dev
mailing list