cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leon Widdershoven <...@dds.nl>
Subject xsp Serverpages generator: Convoluted functionality?
Date Mon, 22 Mar 2004 17:09:31 GMT
Hi,

<abstract>
   I have a question about the design of the ServerPages generator, which
   transforms xsp pages into (at the end) a SAX stream.
   I think the generator wraps to distinct functions into one function,
   and that it could be usefull to split it into a File-like Reader into
   a SAX stream and a separate Transformer which transforms SAX via a
   compilation to another SAX stream.
</abstract>

<pre>
In this e-mail I address a problem which is bugging me almost from the 
start. I have looked at the mailing list but could not find such a 
thread. Whether this is because my idea is stupid or not, I do not know. 
I mean no critique, but i *am* curious.
</pre>

I have noticed that the XSP generator has multiple functions wrapped 
into one:
1. Reading the xsp file (into a DOM tree probably)
2. Transforming this tree into Java
3. Compiling the resulting java file
4. executing this file

After 4) the results is passed further in the pipeline.

I have also noticed that this design results in quite some unnecessary 
trouble for some users, including myself. I try to use the session
authentication data in my xsp pages. But that, naturally, fails since
the session transformer works on the stream that results from the 
serverpages generator. In other words, after the xsp has been compiled.

This means that values from the authentication context cannot be used; 
in effect it means that all logic sheets which do not bind as well to
xsp as esql cannot be used to control the java control flow.

I think this can be done better. It I look at the design concept of the 
sitemap it has generators to load data and transform it into a SAX 
stream, which then is processed by a transformer.

The transformer takes a SAX stream, does it's thing, and returns a SAX 
stream, leaving intact all those tags it can not handle.

At the end the serializer transforms it into the output file which may 
not be a DOM stream.

It I try to map the ServerPages generator into that framework I notice 
it does two separate things:

1. It generates a SAX tree from an xsp file

2. It transforms a SAX tree into a java file, executes that file, and
    returns a SAX tree

Though the naming is quite suggestive, I think the point is clear. I 
think the ServerPages generator should actually be split into two parts. 
That would enable other transformers to handle their tags, after which 
the Java control flow can take that data into account. Such a construct 
would allow non-xsp tags to integrate seamlessly with Java (xsp) programs.

Such a separation of functionality, however, is just so natural that I 
really can't imagine that no-one else thought of that. So I'm actually 
quite curious why such a split has not been done.

I'm also quite curious how the actual implementation of the generator 
works. I have looked at the source code of some xsp tag libraries to get 
other things to work, but I'm a bit scared of the serverpages generator 
- it just has to be complicated. I'm going to look at it anyway in the 
hope that internally the reading of the XML stream and the 
transformation into java is nicely separated, so that I can re-write it 
into two components. If the separation is clean, I think I can do that 
faster than writing my xsl's to handle session-transformed data.

I don't have high hopes, however, so I would really like some comments 
from the people who actually wrote the generator.

Regards,
Leon Widdershoven







Mime
View raw message