cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: [cocoon2] XSP in the new architecture
Date Tue, 28 Mar 2000 21:58:56 GMT
Giacomo Pati wrote:
> 
> Hi folks
> 
> Stefano Mazzocchi wrote:
> >
> > Ok,
> >
> > let's factor this out and let's give the right roles to people so that
> > we don't step on each-other toes.
> 
> <snip/>
> 
> > The missing pieces are:
> >
> >  1) loading generator: should be able to get a class that implements a
> > Generator thru a call cocoon, execute it and hook this generator with
> > its pipeline. It's sort of a generator "stub". Should not perform any
> > internal caching or checks... everything must be done at the engine
> > level so that it can be shared with the other modules.
> >
> >  2) XSP filter: should transform XML that contains XSP taglibs into
> > XSP-only namespace. Consider this a "rotator": all the namespaces axis
> > are _rotated_ to the XSP axis.
> >
> >  3) XSP2Java serializer: should transform XSP into java source code that
> > implements Generator and then pass this thru a java compiler to produce
> > bytecode.
> >
> > [note to who implements this: generators should spit SAX events only.
> > And should _never_ call new String() or deal with strings. They should
> > use char[] almost all the time, performing the i18n encoding at compile
> > time to improve performance. It should also make sure to implement
> > Modificable and allow the XSP to override the hasModified() method.
> > Performance of the compilation is of minimal importance]
> >
> >  4) the sitemap/caching system must be aware of the ability to have
> > subpipelines for generators. And it must be able to cache the
> > subpipeline results.
> >
> >  5) if the XSP2Java uses XSLT to create the java code, the XSLT
> > transformer must be made a component and the XSLTFilter should use the
> > component rather than the XSLT processor directly. (I'll make this
> > change ASAP myself since it's much more elegant)
> >
> > As you see, it's easier to implement and debug it because it's more
> > fragmented and more integrated into the Cocoon2 architecture. There are
> > no overlapping points, there are very few critical points and all the
> > neutron-star dense XSPProcessor code has been factorized into smaller
> > and more practical components.
> >
> > Comments?
> >
> > Any volunteer for the required components?
> 
> Now that I've played with serializers (FO2PDFSerializer), filters
> (LogFilter, SQLFilter) and generators (I've hacked Turbine into a
> generator) I will see if I can write the 1) loding generator. Because it
> depends on some other pieces it gives me time to study the core Cocoon 2
> engine to get that generator working. Or is there anybody else working
> on it? I hope this will motivate others to step in soon to get the beast
> running. 

Ok, people, since I heard no -1 about adding Giacomo, Pier, could you
please grant him CVS access and all that.

thanks.

Giacomo, welcome home :)


-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------
 Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------

Mime
View raw message