Use of flowscript (was: EJB + Cocoon, "Best Practices")

[Reinhard Poetz <re...@apache.org>]

As this may be of some interest for developers I move the discussion to
the dev list.

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

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

I don't understand this. Of course every technology can be abused (IMHO
actions are the best candiate to be abused BTW) but from the mentioned
technologies (including actions) flowscript is the technology that
prevents you best from abuseing it.

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.

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

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.

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

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.

Reinhard


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

RE: Use of flowscript

[Reinhard Poetz <re...@apache.org>]

> -----Original Message-----
> From: Ugo Cei [mailto:u.cei@cbim.it] 
> Sent: Wednesday, September 24, 2003 12:32 PM
> To: dev@cocoon.apache.org
> Subject: Re: Use of flowscript
> 
> 
> Reinhard Poetz wrote:
> > From: Tim Olson
> >>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"
> > I don't understand this. Of course every technology can be abused 
> > (IMHO actions are the best candiate to be abused BTW) but from the 
> > mentioned technologies (including actions) flowscript is the 
> > technology that prevents you best from abuseing it.
> 
> Abusing the flowscript might come in handy. You can do a quick 
> javascript prototype of your logic, test it, then refactor it 
> in Java. 
> This is what we do all the time here.

Yep, I do the same with the business logic (first JS then Java). What I
haven't understood is "it's too tempting for someone to put 
code in the view layer to just 'get it done'".

Reinhard

Re: Use of flowscript

[Ugo Cei <u....@cbim.it>]

Reinhard Poetz wrote:
> From: Tim Olson
>>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"
> I don't understand this. Of course every technology can be abused (IMHO
> actions are the best candiate to be abused BTW) but from the mentioned
> technologies (including actions) flowscript is the technology that
> prevents you best from abuseing it.

Abusing the flowscript might come in handy. You can do a quick 
javascript prototype of your logic, test it, then refactor it in Java. 
This is what we do all the time here.

	Ugo

-- 
Ugo Cei - Consorzio di Bioingegneria e Informatica Medica
P.le Volontari del Sangue, 2 - 27100 Pavia - Italy
Phone: +39.0382.525100 - E-mail: u.cei@cbim.it