cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giacomo Pati <>
Subject Re: generator based including
Date Thu, 11 Jan 2001 21:59:38 GMT
Ok, I think I have to step in :)

Torsten Curdt wrote:
> > "Torsten Curdt" <> wrote:
> > > > > <util:include-xsp uri="file:///something/included.xml"/>
> > > > >
> > > > > Works quite well - as soon as the class representation
> > > > > of "included.xml" is generated.
> >
> > > > > Can anyone think of a way to generate it automatically?
> > > > > Also changes in "included.xml" need to be recognized.
> >
> > Those are exactly what the roles of XSPGenerator are supposed to be, no?
> > Compiling and dependency tracking.
> Yeah, that's what I thought. So the util:include-xsp adds the given
> file to the dependency list of the requested page. I thought this
> would be enough... obviously it is not! :(
> > > > What is the problem you are trying to solve?  Hopefully
> > > > we can come up with the elegant solution...
> > >I hope so as well! I want to be able to include a XSP page
> > >into another one.
> >
> > I have changed my mind on this. I don't like it so much. Here's why.
> >
> > I only became aware recently of the Servlet 2.2 spec's support for
> > subrequests (including), due to a bug report on cocoon-users. In
> > my opinion
> > this support is very confusing and seems to be a bit arbitrary.
> > This affects
> > XSP including because XSP including is similar - people undoubtedly will
> > want the facility to pass parameters to included pages.
> Hm... yes, passing parameters would be nice ;)
> Shouldn't we try to create things people need?
> > This stems from the fact that the ServletRequest API was apparently not
> > originally designed with subrequests in mind. Thus it is messy.
> Well, inside cocoon we can design everything we want... in a nice
> way... can't we? ;)
> > So, why can't you just use good old logicsheets? Why invent a new
> > way when logicsheets work fine?
> I don't see this as a new way that competes with logicsheets!!
> It is just another include mechanism. It should only compete
> with util:include-* and xinclude:include. (Something left out?)
> Ok, I'll describe why I need such an mechanism. Maybe there are
> other ways you can show me...
> Since we're trying to use Cocoon more for WebApplications than
> just for static sites we definitly need better support for forms!
> (At complex error validation it was a pain!)
> So I started writing a form taglib.
>      ..
>      <form:handler name="theorder">
>        <form:form name="order"
>                   uri="file:///E:/JRUN/servers/default/cocoon2/form/order.xml"
>                   onerror="order"
>                   next="show"
>                   />
>        <form:form name="show"
>                   uri="file:///E:/JRUN/servers/default/cocoon2/form/show.xml"
>                   onerror=""
>                   next="submit"
>                   />
>        <form:form name="submit"
>                   uri="file:///E:/JRUN/servers/default/cocoon2/form/submit.xml"
>                   onerror=""
>                   next=""
>                   />
>      </form:handler>
>      ..
> This is how a set of forms are defined. The form:handler checks the POST
> data and chooses (based on the input validation) the right form to be shown.
> So we have the a main XSP page that includes another XSP page.
> (Of course the including is hidden inside the form:taglib)

What you are doing here is mixing service (controller) and presentation
layer (view). My advice is *DON'T DO IT*. You'll soon find yourself in
troubles and you are trying to solve it with the wrong approach because
yyou are already too deep into it. Instead you should strictly separate
these layers. This is one reason why the sitemap with the different
components exists.

The approach I use is that I have XML/XSP files which represents the
views of my application model (only read access). I write actions for
the form data validation/processing and the write access to the model
(actions in fact are for your business logic or at least adapt them).
And finally let the actions communicate with the other components
(matcher/selector/generator etc.) using the mechanisms the sitemap
offers by returning map values from the actions and use them in src
attributes for your generators. Or use a selector which has the
knowledge between conditions your actions set and the resources that
should be produced based upon these condiftion. That way you don't have
to bind your action directly with your resources.

> My first thought was to use xinclude to get those form-pages. But this
> only works for static XML - not for XSP. (Actually I think this should be
> changed! It is a better way than generator based including. I guess it fits
> more into the C2 concept)
> But still the fastest way is calling the XSP pages itself! They all have
> a class representation when generated - why not using the class directly?!
> Works fine - except for the auto generating of the dependencies...
> > Admittedly, my criticisms also apply to content aggregation - which we do
> > need explicit support for, I agree.

The handling of request (and parameters) for "internal" requests for
content aggregation is an issue which is still not clear to me how we
can/should solve it. Stefanos proposal was based on the fact that
content aggregation is based on a defined structure (navigation +
content) and can be solved by an specialized aggregating-generator. This
might help but is not true in general (portals have another structure
that form base apps a.s.o)

> Actually I'm a bit skeptical that sitemap aggregation will do
> what people need... Or better: that this way of aggregation is intuitive.
> I think content aggregation should be "pull" not "push" and sitemap
> aggregation can only do "pull" at root element level (as far as I
> understood)

This is a general problem of understanding. Content aggregation at the
sitemap level is a push, that's right, but content aggregation at the
xinclude level is a pull. What we need is an uniform mechanism to get at
those contents directly in a form like:

    URL url = new URL("cocoon://my/internal/uri");

With such a mechanism it would be easy to realize both (push and pull)
variants and we don't have the need to reparse the response again.


> > Okay, on second thoughts, maybe what we should say is, all
> > "internal Cocoon
> > requests" (whether it's content aggregation or Torsten's XSP including)
> > don't follow the Servlet spec model and don't inherit anything from their
> > parent requests, unless it is explicitly passed through as a
> > parameter. That
> > would avoid the confusion.
> Hm... could you explain this a bit more? I don't see the problem...
> Puzzled..
> --
> Torsten
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, email:

View raw message