Remaining Issues for Seaside 3.0 release

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
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

> 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.

Agreed.  Work out bigger features on branches, merge them when they're
ready, release when there are no big outstanding bugs even if only one
or two branches were merged.

Paolo
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

Yup. And maybe we could actually pick one (or two) major features as goals for each release. When that (plus any low hanging fruit we come across in the process) is done: release!

I have a few ideas and we should get a discussion going shortly, but agreed: for now we need to get a release out last week. :)

Julian



_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

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/
[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
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

I think this could turn out to be fantastic timing for WebVelocity 1.1
and potentially VisualWorks and ObjectStudio.

Michael

On 4/15/10 12:41 AM, Lukas Renggli wrote:
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

On 4/15/10 12:41 AM, 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?
  

Just two issues for me:
http://code.google.com/p/seaside/issues/detail?id=541 and
http://code.google.com/p/seaside/issues/detail?id=532

Cheers,
Michael

_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

> Just two issues for me:
> http://code.google.com/p/seaside/issues/detail?id=541 and
> http://code.google.com/p/seaside/issues/detail?id=532

I've tagged them as 3.0. They are pretty easy to fix, but if you
happened to have the changes you did in VisualWorks that would speed
things up.

Lukas

--
Lukas Renggli
www.lukas-renggli.ch
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

> 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.

Hi Raza

I cannot reproduce the problem by embedding
WAFlowConvenienceFunctionalTest into Pier. It works for me. What are
the exact steps that I need to follow to reproduce a fresh Pier image
and WAFlowConvenienceFunctionalTest?

Furthermore can you verify that in your installation the configuration
of the Pier system uses the settings displayed in the attached
screenshot?

Lukas

--
Lukas Renggli
www.lukas-renggli.ch

_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

Hi Lukas,

Many thanks for your consideration and feedback!

At 21:50 15/04/2010, Lukas Renggli wrote:
>I cannot reproduce the problem by embedding
>WAFlowConvenienceFunctionalTest into Pier. It works for me.

I understand, it shouldn't be easy to reproduce since I'm probably
using that mechanisms in somehow unconventional/unexpected way, w,r,t
the design of partial continuations in Seaside 3.

>What are
>the exact steps that I need to follow to reproduce a fresh Pier image
>and WAFlowConvenienceFunctionalTest?

I've to work on this, and also double check my code. I'll be back on
this topic asap, probably during this week-end.

>Furthermore can you verify that in your installation the configuration
>of the Pier system uses the settings displayed in the attached
>screenshot?

Yes, that's exactly that.

Later,
Regards,
Reza

_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

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
 


_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

At 14:09 15/04/2010, you wrote:
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


_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

This seems very uncommon usage of Pier and #call:. The method
#onAnswerCommand: is called from the answer processing of Seaside, you
cannot call from within there. That should never have worked.

Instead override #doAnswer in the PRAddCommand and answer with a
context that points to a new command that displays the component/task.

Lukas

On 17 April 2010 10:41, Reza RAZAVI <[hidden email]> wrote:


--
Lukas Renggli
www.lukas-renggli.ch
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

At 14:22 17/04/2010, Lukas Renggli wrote:

This seems very uncommon usage of Pier and #call:.

Yes, but please note that the case that I posted is just designed to provide an example. Specifically, the #isKindOf: test on PRAddCommand is there just to limit the impact of my patch in that code. The real case has nothing at all with PRAddCommand per se. It is about launching the execution of  my *composite commands*, in the same way that Pier launches its Commands, so as both types of commands cohabit seamless, while having a conceptually consistent and easy to maintained code. 

The method #onAnswerCommand: is called
from the answer processing of Seaside,

Yes, in general, but, in the case of #isQuick commands, Pier calls it directly (that's basically a shortcut; to reuse the code, as you know better than me 8-) ). And, this is also what I do in the case of my composite/meta-described commands (flow models). In none of these cases Seaside is answer processing, but handling callbacks as follows:
- WAActionPhaseContinuation >> handleRequest
- WAActionPhaseContinuation >> runCallbacks
- PRPierFrame >> update
- PRContentsWidget >> onChangeContext:
- PRContentsWidget >> onAnswerCommand:

This path is most probably not the same in Seaside 2.8; I can double check if necessary. The point is that my image works in Seaside 2.8 (that's basically the one I had during the last BlockParty in Paris).

Let me then ask my question differently: Is the *restriction" introduced in *GRPharoPlatform >> seasideCallbackMarker* is something *unnegotiable* (for example, related to the design of partial executions in Seaside 3, or whatever other fundamental reason)? Or, it would be possible to change it so as to accommodate #call: s in the above frame (#runCallbacks)?

Thank you in advance for your response,
Regards,
Reza
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

> Let me then ask my question differently: Is the *restriction" introduced in
> *GRPharoPlatform >> seasideCallbackMarker* is something *unnegotiable* (for
> example, related to the design of partial executions in Seaside 3, or
> whatever other fundamental reason)? Or, it would be possible to change it so
> as to accommodate #call: s in the above frame (#runCallbacks)?

The point is that:

1. You should not #call: from within the answer handing.
  - Seaside 2.8 incorrectly performs the call, incorrectly aborts the
answer handling at a random point and resume the wrong answer handling
when the called component answers.
  - Seaside 3.0 correctly throws an exception about the missing
marker. #call: is not possible at that point.

And the second point is Pier related and further discussion be moved
to the Pier mailing list:

2. You should not #call: from anywhere within the command execution of
Pier. Numerous assumptions will be broken in subtle ways (critical
sections, atomic execution of commands, persistency, error handling,
...) when you interrupt this critical code using #call:. Simply don't
do it, it does not work and is not supposed to work. As I said, use
the mechanisms Pier provides to display Seaside components (embedding,
#doAnswer, ...).

Lukas

--
Lukas Renggli
www.lukas-renggli.ch
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

At 16:51 17/04/2010, you wrote:

1. You should not #call: from within the answer handing.

I don't call within the answer handling (please see the example below).

  - Seaside 2.8 incorrectly performs the call, incorrectly aborts the
answer handling at a random point and resume the wrong answer handling
when the called component answers.
  - Seaside 3.0 correctly throws an exception about the missing
marker. #call: is not possible at that point.

Somehow surprised about Seaside 2.8, but well noted; thanks for the clarifications and excellent work.

2. You should not #call: from anywhere within the command execution of
Pier.

I don't call from within the command execution of Pier either (I'll send a short email to the Pier mailing list to explain this).

To see the exact issue that I talk about, please just change the following:
PRContentsWidget >> onChangeContext: aContext
        super onChangeContext: aContext.
        self call: WAFlowConvenienceFunctionalTest new

No change is necessary in #onAnswerCommand:.

Then, if you point your browser to http://localhost:8080/pier, you should get that Seaside error.

My goal has basically been to clarify whether that's an expected behavior in Seaside 3.0 or a bug?

FYI, I just double checked with the current distribution of Pier (Pharo0.1, Latest update: #10374), which looks like still based on Seaside 2.8, and the above change doesn't raises an error. On the contrary, the WAFlowTest application (that replaces WAFlowConvenienceFunctionalTest, since absent from that image) is launched and looks like working OK (although I perfectly believe you that this may have its own *internal* issues, as you described above). 

Regards,
Reza
 


_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev