Jos,
You got it right, you use action and action results in the Page Flow,
and sub-pipelines, to implement that kind of flow.
o Your action condition matches "add-to-cart" for example and runs the
"add-to-cart.xpl" pipeline.
o "add-to-cart.xpl" validate your input. You are free to call another
pipeline to do that.
o "add-to-cart.xpl" checks item availability. In function of this, it
returns a document, for example <available>true</available> or
<available>false</available>.
o In the Page Flow, depending on the result of the action, go to page2
or page3.
The idea behind actions is to react to _user_ actions. There may be
multiple such actions in a page, like "search", "add", "remove",
etc. Then the logic of the action is implemented in the relevant
action pipeline.
I understand why you would think it natural to put execution steps in
the Page Flow, but "cascading actions" does not seem to me that it
responds to this original idea. On the other hand the mechanisms to
implement sequences of tasks are fully supported by XPL.
The strength of the current Page Flow / XPL combination is that
concerns are well separated:
o Page Flow handles pages, forms, actions, and the MVC architecture.
o XPL handles pipeline execution, without any notion that it deals
with web pages or even a web application.
It is a delicate balance between what you delegate to the Page Flow
and what you keep in XPL. The tendency is big to add more and more to
Page Flow...
-Erik
Jos Vos wrote:
> Hi,
>
> When defining a page flow, it seems that at most one action pipeline
> is executed (as only the first action with a when-condition yielding
> "true" is used). Is this correct?
>
> What I want to achieve, is to be able to specify a multi-step page
> selection. For example, after a user has submitted a form (page1),
> requesting to add an item to a shopping cart, these are the steps:
>
> - User input is validated. If invalid, show page1 again.
>
> - User input is processed (step1). If the item added is not
> on stock, page2 ("not on stock - proceed or not?") is shown.
>
> - User input is processed (step2). The item is on stock and a
> confirmation is given to the user (page3).
>
> I could give more complex examples, with even more choices, but
> the above example shows the principle.
>
> If you only can execute one action pipeline, this pipeline has to
> implement *all* the conditonal subchoices (like whether the item is
> added to the cart or not), and give back the status, so that the
> <result when=...> can select the next page.
>
> What is the best way to implement this? My first guess would be
> to let the single action pipelines call subpipelines, as a kind
> of subroutines, doing the subprocessing. One pipeline for stock
> checking, one pipeline for adding the item to the shopping cart,
> etc., so that the action pipeline itself in fact only implements
> the logic. Is this a proper way to do this?
>
> I first expected that multiple actions could be "executed", which
> would enable a <result> with no page attribute to (x)update the
> instance, and trigger one of the next actions to be executed in
> sequence, but this appears not to be possible (sadly, as I think
> it would be a nice feature...).
>
> Thanks,
-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
_______________________________________________
orbeon-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/orbeon-user
