cocoon-dev mailing list archives

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

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

<snip/> 

> 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>
    <filter name="xsp"/>
    <serializer name="xsp2java">
   </generator>
   <filter name="xslt">
    <parameter name="stylesheet" value="index-html.xsl"/>
   </filter>
   <serializer name="html"/>
  </process>

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.

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

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.

Giacomo

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

-- 
PWR Organisation & Entwicklung            Tel:   +41 (0)1 856 2202
Giacomo Pati                              Fax:   +41 (0)1 856 2201
Hintereichenstrasse 7                     Mailto:Giacomo.Pati@pwr.ch
CH-8166 Niederweningen                    Web:   http://www.pwr.ch

Mime
View raw message