cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Reinhard Poetz" <reinh...@apache.org>
Subject RE: Use of flowscript (was: EJB + Cocoon, "Best Practices")
Date Wed, 24 Sep 2003 15:29:51 GMT

> From: Tim Olson
> > From: Reinhard Pötz
> > > From: Tim Olson

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

ah, okay. this requirement is neither an argument for nor against
flowscript (it should be very easy to implement it using flowscript)

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

nonono, flowscript is *another* layer, it controlls your application
(--> controller). It decides which pipeline is sent to the client (-->
view) and also decides which data this pipeline uses (--> model).

> it's how you traverse from one UI page to the next.  no?

yes that' correct but also much more: 

 - flowscript gives you the possibility to describe the logic 
   of your application at one single place (it does everything
   a controller has to do)
 - the state of your application is *frozen* using continuations and 
   you don't have to find out each and every time the current state 
   of your application
   --> this also solves the back-button problem
 - a page sent to the client doesn't have any information which
   page comes next

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

also your controller needs rules which page follows another page. You
wrote your own solution which is fine. Since 2.1 flowscript would be
another possibility how you can do it

The things that make flowscript so cool:

 - continuations
 - short write/test cycles (no restart of your container)
 - single point that describes your application
 - javascript is less verbose than java

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

What you did is you wrote a controller for your application and this is
of course fine. This controller does a lot and I claim everything can be
done with flowscript too. Additionally flowscript brings some more
advantages as mentioned above.

Reinhard


Mime
View raw message