You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Torsten Curdt <tc...@dff.st> on 2000/12/12 12:50:46 UTC
RE: XSPGenerator
Yes! This seems to work!! 8-))
But we need the generateContent() method.
This must be changed when generating the java code.
So can we change the XSPGenerator class? Are there any
Problems that I might not see?
That would bring at least full page content aggregation!
--
Torsten
> -----Original Message-----
> From: Torsten Curdt [mailto:tcurdt@dff.st]
> Sent: Tuesday, December 12, 2000 11:22 AM
> To: Cocoon-Dev
> Subject: XSPGenerator (ricardo?)
>
>
> I've some questions regarding the XSPGenerator class.
>
> I'm trying to call a generate methode from another
> XSPGenerator.
>
> class _index_xml extends XSPGenerator{
> public void generate() throws SAXException {
> /* some SAX */
>
> /* create an instance of _include_xml */
> /* later on include.xml should appear in the */
> /* dependencies */
> _included_xml g = new _included_xml();
>
> /* copy the needed attributes */
> g.setContentHandler(this.contentHandler);
> g.setLexicalHandler(this.lexicalHandler);
>
> /* direct output from the other XSPGenerator */
> /* in the same pipeline */
> g.generate();
>
> /* some SAX */
> }
> }
>
> class _included_xml extends XSPGenerator{
> public void generate() throws SAXException {
> /* some SAX */
> }
> }
>
> 1. Do I need to do a full copy of all attributes?
> (if then - what about implementing cloneable?)
> Which are required for the generate to work
> properly?
>
> protected javax.servlet.http.HttpServletRequest request
> protected javax.servlet.http.HttpServletResponse response
> protected javax.servlet.ServletContext context
> protected org.apache.avalon.ComponentManager manager
> protected org.xml.sax.EntityResolver resolver
> protected java.util.Map objectModel
> protected org.apache.avalon.Parameters parameters
> protected java.lang.String source
> protected org.apache.log.Logger log
> protected org.xml.sax.ContentHandler contentHandler
> protected org.xml.sax.ext.LexicalHandler lexicalHandler
>
> 2. Do I need to initialize anything else when creating
> a XSPGenerator this way? (Sorry, to bother you I'm
> still not that into the C2 source code)
>
> 3. Calling another generate method would give us another
>
> this.contentHandler.startDocument();
> this.contentHandler.startPrefixMapping("xsp",
"http://apache.org/xsp");
this.contentHandler.endPrefixMapping("xsp");
this.contentHandler.endDocument();
I guess they shouln'd be called since there are
alreay some in the pipeline, right?
What about having two methods in XSPGenerator then?
class _included_xml extends XSPGenerator{
public void generateContent() throws SAXException {
/* SAX */
}
public void generate() throws SAXException {
this.contentHandler.startDocument();
this.contentHandler.startPrefixMapping("xsp",
"http://apache.org/xsp");
generateContent();
this.contentHandler.endPrefixMapping("xsp");
this.contentHandler.endDocument();
}
}
If this is done we could extend the xinclude syntax to
e.g. <xinclude:include parse="xml" type="serverpage" href="included.xml"/>
And voila... basic content aggregation
--
Torsten
RE: XSPGenerator
Posted by Torsten Curdt <tc...@dff.st>.
> >> That would bring at least full page content aggregation!
>
> This probably means _generator-based_ content aggregation.
Well, not necessarily... at least it gives us the possibility
to easily access the SAX events that create the _content_ of a
XSP generated document without the document header and footer.
My initial idea was to use the xinclude transformer for aggregation.
Unfortunately it doesn't work with non-static XML. My idea now
was to give the xinclude transformer the abillity to include
such a page into the SAX stream
The XSP would create just an SAX event in the xinclude namespace.
The xinclude transformer then catches the event, creates a class
instance of the desired XSPGenerator (e.g. _included_xml) and then
sends the SAX events from generateContent().
> A more general approach to [SAX-based] content aggregation
> would be that of aggregating complete sub-pipelines.
>
> Here, the term "pipeline" is being used with a meaning slightly
> different from that of Cocoon's ResourcePipeline class: it means
> a generator plus zero or more transformers, _sans_ a final
> serializer.
Sorry, if didn't use the correct term. I was thinking of a
generator creating (code for) SAX events which enter a "pipeline"
where transformers catch/transform them and in the end they
get back serizalized. (Sorry - I'm a newbie on C2 internals ;)
--
Torsten
Re: XSPGenerator
Posted by Ricardo Rocha <ri...@apache.org>.
>> That would bring at least full page content aggregation!
This probably means _generator-based_ content aggregation.
A more general approach to [SAX-based] content aggregation
would be that of aggregating complete sub-pipelines.
Here, the term "pipeline" is being used with a meaning slightly
different from that of Cocoon's ResourcePipeline class: it means
a generator plus zero or more transformers, _sans_ a final
serializer.
From this perspective, Pipeline extends Generator, so it's possible
for a pipeline to contain another pipeline as its generator.
If we could request the sitemap to create such pipelines, it would
be possible to do content aggregation in a much general way.
This, in turn, calls for caching intermediate results (i.e. SAX
events generated by (sub)pipelines).
If we have a "SAXCacheable" interface that XMLProducer
implementations (i.e. Generators and Transformers) can also
implement, then intermediate pipeline results could be cached
by interposing a "tee" ContentHandler that would take care of
caching generated SAX events (using a mechanism like Stefano's
XMLCompiler). This reminds me of good ole' Unix "tee" command
used in os pipelines for exactly the same purpose...
Well, just an idea..
> I'm trying to call a generate methode from another
> XSPGenerator.
>
> class _index_xml extends XSPGenerator{
> public void generate() throws SAXException {
> /* some SAX */
Calling a generated XSP class directly doesn't sound appealing
to me. We come to depend on otherwise hidden implementation
details like the generated class/package names and the like.
A think a cleaner approach to content aggregation and SAX event
caching is the one (vaguely) presented above, but it involves
revising the way the sitemap currently handles pipelines. Most
notably, it requires separating the notion of pipeline as such
and its final serialization, as well as providing a mechanism
to generate dynamic pipelines on the fly...
Ricardo
===================================================================
Torsten Curdt wrote:
>> Yes! This seems to work!! 8-))
>> But we need the generateContent() method.
>> This must be changed when generating the java code.
>>
>> So can we change the XSPGenerator class? Are there any
>> Problems that I might not see?
>>
>> That would bring at least full page content aggregation!
>
>
> And the page to be included needs to be in the dependencies list!
RE: XSPGenerator
Posted by Torsten Curdt <tc...@dff.st>.
> Yes! This seems to work!! 8-))
> But we need the generateContent() method.
> This must be changed when generating the java code.
>
> So can we change the XSPGenerator class? Are there any
> Problems that I might not see?
>
> That would bring at least full page content aggregation!
And the page to be included needs to be in the dependencies list!
--
Torsten