cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giacomo Pati <>
Subject Re: [cocoon2] XSP in the new architecture
Date Fri, 24 Mar 2000 21:22:42 GMT

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.
> I will try to explain how:
> - the new architecture allows easier implementation of the XSP subsystem
> - how the subsystem is partitioned in more modules
> - how the cache/store modules can be reused
> - how to implement auto-reloading so that every part benefits
> ok, let's start:
> 1) the old XSP subsystem was created out of a single processor. This has
> several problems:
>   - the original document is always parsed
>   - the XSP processor takes care of reloading, compiling, creation and
> all that
>   - much of the reactor needed to be rewritten inside the processor


> so there is no central XSP subsystem but your own sitemaps define how to
> work with the pieces to define page compilers. For example (consider it
> pseudo-sitemap... a bunch is still to be defined)
>  <process uri="index">
>   <generator name="loader">
>    <generator name="file" src="index.xml"
>    <filter name="xsp"/>
>    <serializer name="xsp2java">
>   </generator>
>   <filter name="xslt">
>    <parameter name="stylesheet" value="index.xsl"/>
>   </filter>
>   <serializer name="html"/>
>  </process>
> or equivalently but less verbose
>  <process uri="index">
>   <generator name="xsp" src="index.xml"/>
>   <filter name="xslt">
>    <parameter name="stylesheet" value="index.xsl"/>
>   </filter>
>   <serializer name="html"/>
>  </process>

How about this:

  <process uri="index">
   <generator name="file">
    <filter name="xslt">
     <parameter name="stylesheet" value="index-xsp.xsl"/>
    <filter name="xsp"/>
    <serializer name="xsp2java">
   <filter name="xslt">
    <parameter name="stylesheet" value="index-html.xsl"/>
   <serializer name="html"/>

This is as I thought the way to get the separation of content, logic and
presentation done, isn't it (see the Cocoon 1.x
sample/xsp/clean-page.xml). I think the second sitemap wouldn't work
well because the <generator name="xsp"> will have the problems you
mentioned in 1) above.

BTW: Where comes the stylesheet selection by media-type into play?

> as you see, the generator uses the result of another pipeline to
> generate a class that gets loaded and executed. The
> caching/autoreloading is there almost for free: the output will contain
> as changeable points all the modules that were responsible to create the
> final resource... if anyone of them changes, the cache resource is
> invalidated and the process recreated.


> 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?

I have to have a look into all that code that is already there to fully
understand and see if I'm smart enough to contribute one of the pieces.


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

PWR Organisation & Entwicklung            Tel:   +41 (0)1 856 2202
Giacomo Pati                              Fax:   +41 (0)1 856 2201
Hintereichenstrasse 7           
CH-8166 Niederweningen                    Web:

View raw message