cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Torsten Curdt" <tcu...@dff.st>
Subject RE: generator based including
Date Thu, 11 Jan 2001 20:22:41 GMT
> "Torsten Curdt" <tcurdt@dff.st> 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)

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.

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)

> 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


Mime
View raw message