cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tagunov Anthony" <>
Subject RE: generator based including
Date Thu, 11 Jan 2001 19:48:41 GMT
On Thu, 11 Jan 2001 18:26:30 -0000, Robin Green wrote:

Hello, evrybody!

We here at our company have developed a similar system for Cocoon1.
It features 
  - invocation of the whole Cocoon processing chain (xslt, xsp, xinclude -- anything)
  - passing parameters explicitly to the included XSP page (and NON XSP) pages
  - isolating parameters,cocoocies,headers,user-agent of the original request)
  - flexible caching of the results 
  - completely correct hasChanged() detection

Drawbacks: we have an ugly .getQuery() in our wrapper request.

What we use it for:
  - we have done it to isolate code retriving data from database and caching this data

Why is this necessary?

1.)  job separation

       one developer writes the code operationg on the database (select/updata/delete)
       other just includes the results coming from his page 

       it complicates things a great dead to mix evrything in one XSP page: user-interaction
       and database interaction sometimes

2.)  this feature actually brings modularization into Cocoon paradigms

3.)  we wanted caching of the results retrived from the database BADLY.
       (Actually we have our results being invalidated once in a hour, or manually
        and a features is planned to enable the invlidation from somewhere inside
        the database)
       we also cache the results of other lengthy procedures (XSLT transformations, etc)

How it looks like:
  our mechanism was build after xinclude processor sample.
  The invocatino looks pretty like xinclude invocation.
  The name is Xecute (like Xinclude)
We pass parameters to the page being executed in two ways:

  a)   <incl xecute:href="file.xml">
parameters passed inside form a separate document and it accessible via a special taglib
   b)  <incl xecute:href="file.xml">
             <xecute:param name="a">2</xecute:param>
             <xecute:param name="b">3</xecute:param>
parameters passed in this fashion get put into a special hashtable and are accessible
via a special tablib, via a special processor and in the xslt transformation as <xsl:param
(we had to patch XSLTProcessor, I've alredy posted 'em to the list. They also allow passing
extra parameters to be passed to XSLTProcessor manually, via a spcial processor and fix
the problem with getting parameters back in good shape if they were passed in UTF-8 or

We had a hard and hot time with caching. Our caching keys actually are string representations
of the parameters passed at invocation concatenated to the filename.

We had to break the .getQuery method of the request (we used our own wrapper, as 
we run on pre Servlet2.3 system ;). It now returns the string representation of the
parameters passed at invocation type (nearly an xml document serialized to string, but not
We had to do it to make the Monitors account our request wrappers propelly and we made them
do it.

Surely we have cut off all the parameters, headers and cocoocies from the original request.
Parameters are passed only explicitly.

And our mechanism invokes all the Cocoon processing chain -- all the processors from the very

Thus we can cache the results of lengthy XSLT procedures as well -- Caching is not a bad thing,
is it? We even cache via this mechanism results of xinlcude on URL-s (retriving via web
is lengthy, so we cache the data that comes from our partners in XML format via web)

If it were completely in-Cocoon calls w/o faking the request and having to mess with 
the .getQuery to deceive the processors and make 'em detect hasChanged() propelly
we would be JUST HAPPY!  
>"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.
>> > Is this for Cocoon 2?
>> > 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.
>According to the servlet 2.2 spec, if you ask for the request parameters you 
>get the parent request AND the subrequest parameters. However if you ask for 
>the query string you only get the parent request's parameters. Likewise, if 
>you ask for one kind of path, you get the parent requests' path, whereas 
>another kind of path gives you the subrequests' path. It is not intuitively 
>obvious what's going to happen when you make a ServletRequest call from a 
>subrequest - and it's even worse in Cocoon 1 which has to support pre-2.2 
>This stems from the fact that the ServletRequest API was apparently not 
>originally designed with subrequests in mind. Thus it is messy.
>So, why can't you just use good old logicsheets? Why invent a new way when 
>logicsheets work fine?
>Admittedly, my criticisms also apply to content aggregation - which we do 
>need explicit support for, I agree.
>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.
>But I'm still not convinced that XSP including is sufficiently useful. Could 
>we have a more concrete, detailed example of how it is better than 
>Get Your Private, Free E-mail from MSN Hotmail at
>To unsubscribe, e-mail:
>For additional commands, email:

View raw message