cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Piroumian Konstantin <>
Subject RE: [Q] Sustainable design with cocoon ???
Date Tue, 16 Jul 2002 15:41:01 GMT
> From: Berin Loritsch [] 
> > From: Artur Bialecki [] 
> >  
> >  Ok, here is the situation.
> >  
> >  Let's say I have some EJB business objects with methods that 
> >  provide DOM view of their data which I want to display to 
> > users.  Other methods take data and update the objects.  All 
> > methods throw exceptions when bad data/system/connection/etc. 
> >  which are handled by redirecting (externally or internally)  
> > to same or some other page PRESERVING the error and 
> > request/sitemap  parameter information. Each page can 
> > view/update several methods.  Hmmm, I think I've seen this 
> > somewhere before ;)
> >  
> >  Currently (C2.0.2) I can do this with heaps of actions which 
> >  parse the request, set/get the data, save the DOM as request 
> > attribute,  which is then picked up by the XSP. If error is 
> > thrown in action  I redirect to predefined page or fail and 
> > let the sitemap deal with it.
> <snip/>
> It looks like you are ready to integrate your own components into
> the cocoon system.  Cocoon is built on the Avalon framework, and it
> is very easy to integrate your own components.
> For a primer, check out
> which brings you through the thought processes of developing with
> Avalon--it also gives you a better idea of how Cocoon operates
> internally.
> Your logic for managing your data should be encapsulated in one
> component.  That component can take care of all the nitty gritty
> details of updating the data--making the option of writing actions
> or XSP logicsheets much easier.
> At that point, you would write either one (1, uno, un, aik) action
> to handle all the integration points with your management component,
> or do it with XSP.

1. I have a very simple sample for this kind of approach. Actually, I have
two actions: to start a new flow and to continue a started one. All the
business logic is encapsulated in one class (that should be an Avalon
component in a real system). The logic handles also all the errors and
returns the page that should be displayed (including error pages). The
relevant part of the sitemap looks like this:

			<map:match pattern="process/start">
				<map:act type="start-process">
					<map:read src="jsp/{start-page}.jsp"
				<map:read src="html/error.htm"/>
			<map:match pattern="process/input">
				<map:act type="input-process">
src="jsp/{current-page}.jsp" mime-type="text/html"/>
				<map:read src="html/error.htm"/>

I use jsp reader here, but a better approach could use <map:call /> to have
better separation between presentation and logic parts.

2. Another option is to use the Flow sub-system developed by Ovidiu. It is
concidered to be more powerful and flexible approach than having all the
integration logic in actions or a component. It's based on JavaScript and
you can call Cocoon actions and components directly from a script without
need to recompile classes.


> I encourage you to view XSP (like you should view JSP) as strictly
> a presentation layer.  That way your XSP logicsheet focuses on
> extracting the data, and your action focuses on manipulating the
> data.  Rest assured, when actions are removed something better will
> take their place.  Until that time it is safe to use them.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, email:

To unsubscribe, e-mail:
For additional commands, email:

View raw message