Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Message-ID: <40615A67.8090403@upaya.co.uk>
Date: Wed, 24 Mar 2004 09:52:39 +0000
From: Upayavira <uv@upaya.co.uk>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.4) Gecko/20030624
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: xsp Serverpages generator: Convoluted functionality?
References: <405F1DCB.3020304@dds.nl>
In-Reply-To: <405F1DCB.3020304@dds.nl>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Leon,

Thank you for your detailed consideration of the ServerPages generator.

As I understand it, the ServerPages generator is primarily used with 
XSP. These days, XSP isn't a primary and recommended tool within Cocoon. 
It is primarily there to support existing users. Alternative methods are 
available that should enable you to achieve everything you can do in 
XSP, such as FlowScript and JXTemplate.

Therefore, whilst I do sense some merit in what you write, I do not 
expect anyone here to be interested in modifying or rewriting the 
ServerPages generator. It works, and that, for us, is good enough.

If you wish to carry on using XSP, that's fair enough - otherwise I'd 
encourage you to try Flowscript and its associated methods (including 
the CompilingClassLoader that allows flowscripts to use Java code that 
is compiled on the fly, without restarting your servlet container). If 
you start using these technologies, then you'd be more than welcome to 
join us in the development effotrt that is going on around improving 
them, and in terms of learning how best to use them.

Hope this helps, and is clear enough.

With best wishes,

Upayavira

Leon Widdershoven wrote:

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