cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Piroumian Konstantin <KPiroum...@protek.com>
Subject RE: [Q] Sustainable design with cocoon ???
Date Tue, 16 Jul 2002 15:41:01 GMT
> From: Berin Loritsch [mailto:bloritsch@apache.org] 
> > From: Artur Bialecki [mailto:artur@digitalfairway.com] 
> >  
> >  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 http://jakarta.apache.org/avalon/developing/
> 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"
mime-type="text/html"/>
				</map:act>
				<map:read src="html/error.htm"/>
			</map:match>
			
			<map:match pattern="process/input">
				<map:act type="input-process">
					<map:read
src="jsp/{current-page}.jsp" mime-type="text/html"/>
				</map:act>
				<map:read src="html/error.htm"/>
			</map:match>			

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.

Konstantin

> 
> 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: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
> 

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


Mime
View raw message