Stefano Mazzocchi wrote:
On 11 Nov 2003, at 05:47, Antonio Gallardo wrote:
Sylvain Wallez dijo:
Let's reformulate this into a proper vote.
Do you want to enforce the fact that flowscript calls (either "function"
or "continuation") *must* redirect using sendPage, sendPageAndWait or
redirectTo and that, should it not be the case, a ProcessingException be
raised?
[ ] no, let the sitemap execution continue after the <map:call> if there
was no redirect.
[X] yes, enforce it in 2.1.3
[ ] yes, enforce it in 2.1.4
Earlier means less pain in the future.
Agreed, +1
I'm -0 on "yes, enforce". Not sure why it should be disabled.
I'm the same. In fact, I think that flow in some cases needlessly complicates the composition of a pipeline. Now I have to have two pipelines where I used to need one. I have to have one that matches the external request and calls the flow function, and another one for the default result of that pipeline. So far this has felt like needless additional complexity to me (and I think will to others).
To try to make this point a little clearer:
Part of the beauty of the sitemap prior to flow was that you could at a glance see what each request url was triggering. Now, I look at the sitemap, have to locate the flowscript, parse through it for the various sendPage etc. and then back to the sitemap to find where the action really happens. This could perhaps be handled with some best practice naming conventions. Perhaps a practice of passing in the various possible view uris to the flowscript should be considered. I don't know.
I'm not negative on flow, and not positive on actions - just pointing out a loss of readability of the sitemap that has resulted from our move forward.
So actually, I'll say I'm -.5 on the need to enforce this at all.
Geoff
