<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
