> From: Berin Loritsch [mailto:[EMAIL PROTECTED]]
> > From: Artur Bialecki [mailto:[EMAIL PROTECTED]]
> >
> > 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: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
