RE: EJB + Cocoon, "Best Practices" (became Flow Script discussion )

[Tim Olson <ti...@myadguys.com>]

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

Re: EJB + Cocoon, "Best Practices" (became Flow Script discussion )

[Steven Noels <st...@outerthought.org>]

Tim Olson wrote:

> there are a few reasons we didn't use flow scripts even though they are
> quite cool technologically.

<snip type="nice rationale"/>

Out of the blue: did you take a look at the (hopelessly underdocumented) 
Apples controller?

</Steven>
-- 
Steven Noels                            http://outerthought.org/
Outerthought - Open Source Java & XML            An Orixo Member
Read my weblog at            http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org                stevenn at apache.org


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

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

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