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 17:29:57 GMT

> From: Tim Olson [mailto:tim@myadguys.com] 
> 
> 
> > > 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)
> 
> oh?  i'd like to hear about that.

as you described your scenario you collect xml streams and write them in
some store (whatever this store is - maybe an object in the users's
session). This can be easily done with flowscript.

Then, to provide a view of your store can be done using a pipeline with
a generator capable reading this store.

> 
> 
> > > 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).
> 
> well for the scale of our application, the controller logic 
> needs to be on the backend servers.  our "controller" is 
> really just a forwarder that can be sequenced.  

if you want to have your controller at your backend just use it, why not
from within your flowscripts.

> in some ways 
> it's less powerful than flowscript, which is intentional. you 
> could make the same argument that ASP/JSP/XSP code is also 
> controller code, but the entanglement with the view is clear.

show me how you can separate the view from the controller with e.g. asp
or php?

> 
> 
> >  - flowscript gives you the possibility to describe the logic 
> >    of your application at one single place (it does everything
> >    a controller has to do)
> 
> ok, but it's the wrong place for us.  most of the controller 
> logic needs to be on our business process servers, not the 
> web servers.

as mentioned, then use flowscript to access your backend controller

> 
> 
> >  - 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
> 
> nice.  p.s. what kind of performance penalty does freezing 
> the application state involve?  

from my experience there aren't any performance penalties but I'll try
to come up with some tests in the next weeks.

> what is included in 
> "application state"?  

with an application state you have connected a certain point in the
script where execution stopped. every use can create infinite
continuations (you can invalidate them directly otherwise they are
automtically invalidated after some time out) but all the values frozen
exist only once. So if the user changes one value in browser window A
and then the same in browser window B and he jumps back to A he will see
after a refresh the value entered in window B.

this behaviour is the same wheter you use simple javascript variables or
any Java objects.

> what about all the state in our EJBs 
> and other backend services?  that still would need managed of course.

what do you mean with "managed"?

> 
> 
> >  - a page sent to the client doesn't have any information which
> >    page comes next
> 
> for us, the page that gets sent to the client has ALL the 
> info about what comes next, 

IMO this is mixing of concerns because it's not part of the view layer
to know what comes next

> and our controller has very 
> little of it.  that allows our designers to change the site 
> flow with very little tweaking (if any) in the controller.
> 
> 
> > > 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
> 
> actually the controller doesn't know about which page follows 
> another; this is important.  our view layer provides an exit 
> key and an entry key.  the exit key triggers a series of 
> activities which cleans up from any posted data etc from the 
> page just left.  the entry key identifies and prepares the 
> new page.  with this scheme, we are able to mix-and-match 
> pages in our view layer without modifying the controller.
> 
> 
> honestly, i'm not happy about having to write our own 
> solution.  

what do you mean with your 'own solution'? The connection from within
Cocoon to your backend controller?

> if flow script could emit XML 

see above (I've the feeling I'm overlooking something important for you)

> and invoke remote 
> EJBs then we might use it.

this shouldn't be too difficult as flowscript gives you all
possibilities

> 
> it seems that cocoon is taking the direction of trying to 
> be/do everything, but i'd rather have a fast, stable XSL 
> pipeline engine that can integrate well with other 
> technologies.  we already have app servers that work great; 
> we just needed a better view solution.

Take what you like! The cocoon project was founded as a web publishing
environment (what you call 'xsl pipeline engine' - but it's much more
than this) but has evolved to a web application framework. This is the
core of Cocoon. Everything else will be factored out into blocks (see
the blocks discussion).

Reinhard



Mime
View raw message