cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Olson <...@myadguys.com>
Subject RE: EJB + Cocoon, "Best Practices" (became Flow Script discussion )
Date Tue, 23 Sep 2003 16:09:38 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.

--> 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, disjoined from the
business objects they work with.  granted, if you write them correctly they
are simple, but i've never seen this in practice.  it's too tempting for
someone to put code in the view layer to just "get it done"

--> flow scripts encourage you to link multiple pages together into a
series, but i think this is a bad idea in terms of maintenance.  on any
given page of our site, there are 20-50 outlinks for the user to choose
from, so it's very important for us to maintain modularity between pages.
to achive this, we've broken our backend actions into two parts: actions you
invoke while leaving page A and actions you invoke while entering page B.
we then can mix-and-match page A to page C or C to B etc.  writing flow
scripts which cross page boundries would make our navigation logic a
nightmare.

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


> -----Original Message-----
> From: Christopher Oliver [mailto:res1cf5x@verizon.net]
> Sent: Monday, September 22, 2003 11:33 PM
> To: users@cocoon.apache.org
> Subject: Re: EJB + Cocoon, "Best Practices"
> 
> 
> Tim Olson wrote:
> 
> >to get EJBs into cocoon, we have a custom Action / Generator 
> pair.  the
> >action can be configured to make any EJB call (uses 
> reflection) and stuff
> >the results into a HashMap.  the custom generator then sends 
> that hashmap
> >through Castor to generate SAX events.  it's very nice, 
> since we can turn
> >any series of ejb calls into XML data with just a few lines 
> of sitemap code.
> >note: remote interfaces are tricky to castorize so use the 
> value object (aka
> >data transfer object) pattern.
> >
> >we eschewed flow scripts and wrote our own action engine, 
> but i should post
> >separately about that.
> >
> >  
> >
> Why did you "eschew" flow scripts? Just curious.
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
 

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Mime
View raw message