> > there are a few reasons we didn't use flow scripts even
> > though they are quite cool technologically.
> >
> > --> we wanted to execute a series of actions which can not
> only follow
> > different paths like selectors but can also emit XML which is
> > concatenated into the response stream. there's no cocoon
> > component like this so we're already into custom code.
>
> it seems very hacky (an action generates XML ...???) to me -
> but maybe I
> haven't got it right
well, when i say "action" i don't mean "cocoon action" because of course
they can't emit xml. by "action" i meant any modular process, like an EJB
call. i'll start calling them "activities" to avoid confusion.
it's very nice to say things like:
1. validate credit card
2. save user's updated credit card info
3. ship order
then at the same time have these three activities push out something like:
<credit-card-validation>
<valid>true</valid>
<authorization>823748927</authorization>
<amount>$99</amount>
<date>2003-09-09</date>
</credit-card-validation>
<profile-update>
<credit-card>
<saved>false</saved>
<failure-reason>User elected to never save credit card
information</failure-reason>
</credit-card>
</profile-update>
<order>
<number>58834</number>
<ship-date>2003-09-12</ship-date>
<product>
<description>Widget</description>
<price>$99</price>
</product>
</order>
activities often have results which need to be displayed by the generated
page, and the emission of XML seems very natural to me.
> > --> flow scripts seem to present the same problem as ASPs,
> JSPs, and
> > --> XSPs in
> > that too much process logic ends up on the web server
> > <snip>
> Back to your scenario: What has "code in the view layer" to do with
> flowscript? Since using flowscript I don't have to do this anymore.
i consider flow script to be part of the view layer. it's how you traverse
from one UI page to the next. no?
> > --> flow scripts encourage you to link multiple pages
> together into a
> > series, but i think this is a bad idea in terms of
> > maintenance.
> > <snip>
> > or C to B etc. writing flow scripts which cross page
> > boundries would make our navigation logic a nightmare.
>
> that's no argument against flowscript because nothing
> prevents you from
> building your decision logic (which page comes next) using
> flowscript in
> a way action do it. You don't have to code explicitly any page2page
> relation.
true, and i believe that (at least for our site), you SHOULDN'T code any
page-to-page relations. but then, what makes flow script so cool?
> > --> the action engine we wrote not only handles long-running-request
> > continuations but can also provide an updated view of the
> > data processing. that is, our long-running backend actions
> > can iteratively add data to the response stream, and our
> > continuation controller will display whatever results have
> > been given so far. this allows us to do things like show
> > progress bars that change with every refresh. while a flow
> > script could be made to do this, you would have to
> > (artifically) break your long-running process into multiple
> > stages and return different pages between each. in our
> > solution, you can have a single long-running stage and a
> > single progress page.
>
> IIUC you have a long running job in the background that gathers data.
> You have two possibilites: You can either wait for the final result or
> you can have a look at the intermediate results.
yes, if the results are not complete, our interstitial pipeline is
automatically invoked with the most up-to-date xml. if the long-running
activities have completed then a different pipeline is invoked.
> To implement this I wouldn't use neither actions nor flowscript - IMO
> both are the wrong place. Both could be used to start the
> processing or
> access your store with the collected (maybe not finished)
> results but I
> wouldn't make the controller to be the store.
i guess my use of the word "action" lead to some misunderstanding. to hack
cocoon, we wrote a cocoon action which merely starts our own action engine
(controller). to charge any of our activity chains from realtime into
long-running, we merely change one attribute on the cocoon action plus
specify an interstitial pipeline.
