[Q] Sustainable design with cocoon ???

[Artur Bialecki <ar...@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.
 
 The problems I see with this approach:
 - sitemap looks like hell with all these actions
 - many places that access data, eg. If I want to add new business data
   to the page, I have to write the action, add the action to sitemap for
   that page, change the page to access data from req. attribute.
 - actions might go away.
 
 I'm also thinking of writing some xsp tags for the business methods
 that access the data and handle exceptions. Then writing a
 Generator from which I can bail out back to sitemap on error.
 This would involve stacking sax events until XSP processing is done.
 This way at least my data access is in one place and near the error handling.
 
 Neither solution is pretty, but right now (2.0.2) I can't see others.
 My questions are:
 - Is there a better way of doing this in 2.0.2 (I don't have all the
   cocoon code memorized :)
 - How will 2.1 solve this in a nice simple way?
 - What can I do to minimize changes needed for 2.1?
 
 And no I CAN'T rewrite my business objects as transformers :)
 
 Thanks,
 
 Artur...
 
 
 
 


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

RE: [Q] Sustainable design with cocoon ???

[Berin Loritsch <bl...@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.

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