[Seaside-dev] Remaining Issues for Seaside 3.0 release

[Reza RAZAVI]

Hello Lukas, all,

I've recently encountered an issue with the new 
implementation of WATask, and feel that I should 
report it now. It has already been shortly 
reported to the Pier mailing list (please see 
emails entitled *Contextual #call: issue*), but 
I've certainly not been explicit enough. So, let 
me first situate briefly the context, and then 
describe that issue. My apologies beforehand for the rather long post.

During the past months, I've been implementing an 
on-line flow modeling and execution tool, which 
has been made possible specifically thanks to 
Seaside and Pier (and the Smalltalk Community in 
general). This tool is particularly useful when:
- The control flow can only be known at runtime 
(with applications, for example, to support daily life activities), and
- The control flow is subject to frequent changes 
in time and space whilst the web application is 
already deployed (for examples of application domains, please see [1]).

Roughly speaking, this tool (framework) is composed of two sub-systems:
- A web interface that complements Seaside and 
the Smalltalk browser in that it allows 
specifying on-line flows of Seaside components 
(equivalent to WATask >> go methods).
- An execution engine (interpreter) that executes those flow models.

Additionally, that execution engine is fully 
integrated in Pier's interpretation cycle. 
Specifically, each flow model behaves as a new 
(isQuick) Command, and its execution is triggered 
by PRContentsWidget. Since, flow models may 
reflect arbitrary interactions between Seaside 
components, including iterations and 
conditionals, once the execution of a flow model 
is triggered, it may involve a (large) number of 
#call: to other Seaside components (as well as 
other types of components).  This has been 
perfectly functioning in Seaside 2.8, and Pier 1.

Now, with Seaside 3.0 and Pier2, I encounter an 
issue that I've unfortunately not yet had time to 
characterize enough, but it looks like that my 
way of calling Seaside components confuses its 
new method of handling callbacks (although it has 
been functioning with Seaside 2.8). Here is a case that happens repeatedly:
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.
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.

What would be the best way to fix this?
Regards,
Reza Razavi

[1] <http://adaptiveobjectmodel.com/>http://adaptiveobjectmodel.com/
[2] Seaside – A Multiple Control Flow Web Application Framework
      Stéphane Ducasse, Adrian Lienhard, Lukas Renggli

At 09:41 15/04/2010, Lukas Renggli wrote:
>We should get a release candidate of Seaside 3 out ASAP. There is a
>significant amount of adoption, no critical bug reports and I don't
>see any obvious issues that would block a release.
>
>I've retagged some issues from 3.0 to 3.1 that I think are not
>critical. There are two issues that I think require some attention
>(correct me if not):
>
>    http://code.google.com/p/seaside/issues/list?q=milestone=3.0
>
>Anything else that cannot be delayed until 3.1? 3.2?
>
>Also I think we should go a little faster and give up on this crazy
>alpha1..n,beta1..n versioning scheme. It does not scale for us. Let's
>release 3.0 now, release 3.1 for ESUG, and 3.2 by the end of the year.
>Each increment with its own small set of valuable improvements and
>bug-fixes. Let's not strife for the "perfect" release.
>
>Lukas
>
>--
>Lukas Renggli
>www.lukas-renggli.ch
>_______________________________________________
>seaside-dev mailing list
>seaside-dev at lists.squeakfoundation.org
>http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/seaside-dev/attachments/20100415/ac430602/attachment.htm