cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From giacomo <>
Subject Re: cvs commit: xml-cocoon/webapp/docs/samples/xsp cookie.xsp
Date Sun, 29 Apr 2001 16:44:51 GMT

On Sun, 29 Apr 2001, Jeremy Quinn wrote:

> At 10:05 PM +0200 19/4/01, giacomo wrote:
> >> So my position is:  XSP for sitemaps, serverpages, flowmaps, actions,
> >> aspects.
> >
> >-1 XSP for sitemaps (XSP is not the right markup-language)
> > 0 XSP for serverpages (already the case)
> >-1 XSP for flowmaps (same as sitemap)
> >-1 XSP for actions (an Action is not generatin any XML so XSP is of
> >                    no use here)
> Hmmm, don't completely agree here, I believe it would be very useful to be
> able to use XSP TagLibs in Action generation.
> For instance, in the Crudlet TagLib, there are tags that retrieve data and
> update a Bean, tags that set things up, trigger Events, and Tags that
> output XML.

Well, you are talking about taglibs. We are talking about XSP and that
means the element available under the XSP namespace. I still don't thing
that anything like <xsp:element> or <xsp:expr> or most of the other
elements makes any sense in an Action, and thus XSP is of no use in
Actions. It is the wrong markup. Of course you can tell us that the fp
or esql logicsheet can be of some use in an Action but it's not the XSP
markup you mean its the java code in there, right?

> It would be extremely useful to be able to do any events, update and
> setting up in Actions, controlled by the SiteMap, and then use Output tags
> within the XSP Page.

I'm not sure to understand you. I already can and do let the sitemap
controll the events and let it dispatch them among Actions. I already
use Actions to update my model and I use Action to update/create my
business objects which gets output later on in the piipeline with
the help of XSP pages. So what do you want more?


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

View raw message