Proposal for XSP extension

[Joerg Henne <jo...@cogito.de>]

Hi,

after some discussion on the cocoon developers list I'd like to propose an
extension to the XSP language specification that is, IMHO, indispensable for
"second-generation" XSP processing systems like Cocoon 2. 

The extension I propose is a new element that allows the declaration of code
that gets executed before the generation of XML output begins. The following
examples assumes that the new element is called "xsl:init", however a
different name might be more appropriate. To illustrate the proposed behavior,
let's suppose there's a logicsheet containing this XSP fragment ...:

	<xsl:template match="example">
 		<xsp:init>
			doSomeInitialisationStuff();
		</xsp:init>
		<xsp:logic>
			generateSomeXML();
		</xsp:logic>
	</xsl:template>

... and a corresponding XML document (fragment) making use of this template
rule:

	<page>
		<some-elemnt/>
		<example/>
		<some-other-element/>
	</page>

This would, in Cocoon 2, result in a XSP generator source code like this
(abbreviated for better readability):

	generate() {
		doSomeInitialisationStuff();
		
		startDocument();
		startElement("page");

		startElement("some-element");
		endElement("some-element");

		generateSomeXML();

		startElement("some-other-element");
		endElement("some-other-element");

		endElement("page");
		endDocument();
	}

The code block contained within the <xsp:init> block has been placed at the
very beginning of the generation method, outside the
startDocument()/endDocument() scope. Code blocks from other
templates/logicsheets as well as code from global XSP blocks would have been
placed there, too. The doSomeInitialisationStuff() method could, for instance,
check if the current user is logged in and send an HTTP redirect to the login
page if he isn't. 
In order to understand why this is important, you have to keep in mind three
facts:

1. Cocoon 2 uses an active, event-driven model, i.e. the XSP generation
produces SAX events that are propagated down the transformation pipeline
(transformation, serialization etc.) in a synchronous fashion.

2. Due to the way XSL processing works, it is possible that the very first
generation event (the startDocument() event) causes output to be produced at
the end of the pipeline. This output may even be sent off to the client.

3. HTTP redirection (sending a "Location"-header) is only possible until the
headers have been sent to the client. Therefore, after the first output has
been generated, it is not possible to send a redirect anymore (if you try to
do it anyway, the servlet engine will throw an IllegalStateException).

Conclusion: on order to be able to use HTTP redirection in Cocoon 2, it is
mandatory to be able to initiate the redirection before the generation of
output has been started. 
Please note that this wasn't necessary in Cocoon 1 where the generation
process is based on a process of consecutive DOM manipulations, because no
output is produced until the final DOM tree is serialized.

There have been objections to the very concept of using redirects from within
XSP pages. However, IMHO the alternatives to redirection, namely using Cocoon
2 style actors or using conditional output generation, either don't seem
viable in all cases or would cause other ugly problems. Of course I'll be glad
if someone convinces me otherwise. :-)

Joerg Henne

Re: Proposal for XSP extension

[Joerg Henne <jo...@cogito.de>]

Paul Russell wrote:
> 
> Hmm. Indeed. I think there's a need for some uniform way of declaring
> global variables and the like, too. At the moment, you can't define code
> which is outside the 'generate' phase of the request explicitly. The
> best you can do is to put an xsp:logic element just inside the
> <xsp:page>. This strikes me as a little ambiguous. I can't help feeling
> there should be an explicit way of achieving it.

You are talking about a way to define code for outside the generate method
from within a template rule? Well, I'm not too comfortable with code outside
the generate method anyway (but of course we need it), or, to be precise, I'm
not comfortable with the way (at least the Cocoon-implementation) XSP works in
general: there is no separation of namespaces for different logicsheets.
Logicsheet implementors have to be very careful to name their variables in a
way that there are no clashes and that's IMHO a violation of the "no
surprises" rule.
Generating global code from within a template rule would at least require
precautions to include the global section of every template rule only once.
Otherwise using the same template twice could cause duplicate variable
declarations etc.

Joerg Henne

Re: Proposal for XSP extension

[Paul Russell <pa...@luminas.co.uk>]

* Matt Sergeant (matt@sergeant.org) wrote :
> On Thu, 4 Jan 2001, Joerg Henne wrote:
> > The extension I propose is a new element that allows the declaration of code
> > that gets executed before the generation of XML output begins. The following
> > examples assumes that the new element is called "xsl:init", however a
> I like the concept, but I'm not mad keen on the name, though I could be
> persuaded that the name is fine.

Hmm. Indeed. I think there's a need for some uniform way of declaring
global variables and the like, too. At the moment, you can't define code
which is outside the 'generate' phase of the request explicitly. The
best you can do is to put an xsp:logic element just inside the
<xsp:page>. This strikes me as a little ambiguous. I can't help feeling
there should be an explicit way of achieving it.

The trouble is that XSP already has a fair few tags, and it'd be good if
we could find some way of integrating the 'xsp:init' proposal with the
above. Anyone got any ideas?


Paul.
-- 
Paul Russell                                 Email:   paul@luminas.co.uk
Technical Director                             Tel:  +44 (0)20 8553 6622
Luminas Internet Applications                  Fax:  +44 (0)870 28 47489
This is not an official statement or order.    Web:    www.luminas.co.uk

Re: Proposal for XSP extension

[Matt Sergeant <ma...@sergeant.org>]

On Thu, 4 Jan 2001, Joerg Henne wrote:

> The extension I propose is a new element that allows the declaration of code
> that gets executed before the generation of XML output begins. The following
> examples assumes that the new element is called "xsl:init", however a

xsp:init you mean :-)

> different name might be more appropriate. To illustrate the proposed behavior,
> let's suppose there's a logicsheet containing this XSP fragment ...:

I like the concept, but I'm not mad keen on the name, though I could be
persuaded that the name is fine.

-- 
<Matt/>

    /||    ** Director and CTO **
   //||    **  AxKit.com Ltd   **  ** XML Application Serving **
  // ||    ** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // **     Personal Web Site: http://sergeant.org/     **
     \\//
     //\\
    //  \\