cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Olson <...@myadguys.com>
Subject RE: Use of flowscript (was: EJB + Cocoon, "Best Practices")
Date Wed, 24 Sep 2003 14:48:23 GMT
> > 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.


Mime
View raw message