[C2 proposal] Alternative to XSP

[Joerg Henne <j....@levigo.de>]

Hi,

we all know and like XSP. However, we also know quite a few of its problems.
Therefore I'd like to propose an alternative to XSP which may be, in many
cases, a viable and much easier to use option.
The basic idea has come up at least once on this list: perform a mapping
between XML space and OO space like this:

- map an XML namespace onto a class which implements certain interfaces
- map XML element names within the namespace onto method names
- pass attributes and children of the mapped element to the method.

This mapping can either be performed in a generator or a transformer. Although
the current implementation only supports the generator option, it already
features a separation of the processing functionality into a separate class
which makes the implementation of the transformer quite trivial.

--- The implementation in detail:

As the classes onto which the XML namespaces are mapped act as delegates in
the production of XML fragments, they have been called "SAXLets".
Consequently, the generator is called "SAXLetGenerator". The SAXLetGenerator
uses a SAXLetProcessor as a delegate for the processing.

The SAXLets must be implementations of avalon Components with an additional
interface SAXLet. The SAXLet interface is currently only a marker-interface
and it has to be seen, if it makes sense to get rid of it in the future.

SAXLets may implement any of the Avalon lifestyle and life-cycle interfaces to
control their management and two more interfaces to control their
configuration:
- SAXLets implementing XMLProducer will be passed a reference to an
XMLConsumer
- SAXLets implementing SitemapModelComponent will be set up like other
SitemapModelComponents
During one processing session, only on instance of each SAXLet will be created
(i.e. retrieved from the ComponentSelector).

The mapping of element names to method names is subject to the following
rules:
- some-element becomes someElement
- ELEMENT becomes eLEMENT
The mapping is currently far from being fool-proof and probably has to be
improved. Methody may be declared without parameters, or as takin an Avalon
Configuration. In the latter case, the SAXLet processor will pass attributes
and children of the mapped element to the method in the form of the
Configuration.

It's quite obvoius that the SAXLetProcessor uses reflection to lookup and
invoke the SAXLet methods. Now, I know your qualms about reflection, however,
I've come to the comclusion that reflection is quite "fast enough":
- It's the lookup of the method which takes a huge about of time. The
invocation using Method.invoke() is much faster. Therefore the implementation
caches the looked-up methods.
- Benchmarks show, that dynamic invocation is (sxcluding the lookup) still
about 30 times slower (on JDK 1.3) than static invocation. However, to put
this into perspective, I've found my machine (900MHz, intel) to take roughly
1us per dynamic invocation. Or, in other words, if a page contains 10 SAXLet
elements, the machine will spend about 10s for 1M-hits on the dynamic
invocation. I think that's a reasonable figure.

Methods may produce output three ways:
- A method may return an scalar Object. In this case the Object will be
converted to String and, wrapped in an element of the same name as the
invoking element, and sent down the pipeline.
- A method may return an array of Objects. This is the same as the scalar
case, just that ther will be an element with content for each array element.
- A method may produce SAX events on it's own. In this case the SAXLet must
implement XMLProducer, so that the reference to the consumer is available. The
XML events will be filtered through a XMLFragmentCompleter (a new utility
class) which makes sure that the XML is well-formed even in the case of
premature returns.

Excetions thrown by the SAXLet methods are caught, logged, and re-trown
wrapped in SAXExceptions.

The implementation comes with a very simple example, the RequestSAXLet, which
re-implements the functionality of the request logicsheet as a SAXLet. The
sample has ist's own sub-sitemap, the mounting of the sub-sitemap is up to
you.

--- Future stuff and RT

Obviously, XSP can do a few things that SAXLets can't do, e.g. iteration and
conditional processing of the input. However, one could argue that the need
for iteration or conditional processing is an indication for a possible mixing
of concerns. On the other hand, at least iteration and conditionals could be
implemented, albeit in a less natural way than the simple delegation of the
XML production.

Currently, the generator does not support caching. However, SAXLets could very
well implement Cacheable so that the cacheable descision could be delegated to
the SAXLets. We intend to add this RSN.

An additional performance improvement for the Generator can be achieved by
caching the input events together with the references to the SAXLets and their
methods, in order to get rid of the parsing of the input and lookup of the
namespaces that is currently necessary.

--- 

I suppose that some of you will hate the SAXLet approach as it is quite
incompatible with XSP and breaks all the current value-added functionality
(logicsheets). But please let your comments roll in. 

Joerg Henne

Re: [C2 proposal] Alternative to XSP

[Stefan Koehler <st...@interface-projects.de>]

Joerg,

> True, the exception handling is currently sub-par. It's currently high on
> my to-do list :-)

At least you could simply pass exceptions from SAXLet methods to the logger 
as second parameter.

>
> > > What they (currently) can't do:
> > >
> > > - they can't be nested within one another because the SAXLet processor
> > > doesn't know anything about the semantics of a SAXLet element. Thus
> > > contained SAXLet elements would simply be passed to the containing
> > > SAXLet element's method.
> >
> > This is a serious restriction. Perhaps nesting could be realized by not
> > passing Configuration objects directly but a subclass which calls the
> > SAXLet processor for childs that reference SAXLet methods (only a
> > thought).
>
> I like the idea. It's similar to what JSP does and the need to pass this
> object can be determined by looking at the method's signature. However, I
> think the DefaultConfiguration has the restriction that it does not support
> element content and children at the same time. Therefore we'd need
> something else.

Do you mean something like this:

<saxlet:method-whith-text-argument>
  Some content as argument <othersaxlet:method/> Whatever else.
</saxlet:method> 

had to be substituded with something like that:

<saxlet:method-whith-text-argument>
  <util-saxlet:concat>
  	<util-saxlet:part>Some content as argument</util-saxlet:part>
	<util-saxlet:part><othersaxlet:method/></util-saxlet:part>
	<util-saxlet:part>Whatever else.</util-saxlet:part/>
  </util-saxlet:concat>
</saxlet:method-whith-text-argument> 

?

> Do you have any ideas on the semantics of this approach? Doing thinks like
> mixing random XML with field data from an SQL query in a loop would be
> fairly straight forward (just making this up):
>
>    <foo:execute-query id="some-people" sql="..." maxrows="10"/>
>    <foo:foreach-row query-id="some-people">
> 	<person>
> 		<firstname><foo:get-field name="firstname"/></firstname>
> 		<lastname><foo:get-field name="lastname"/></lastname>
> 	</person>
>    </foo:foreach-row>
>
> But this could also be solved with simple XSLT operations. What more could
> there be?

You're right, this can be done with XSLT. I currently have no relevant example 
for loops like this in mind. 
But can you take the result from one query to build another one?

Imagine a SAXLet which renders a person by name (for example from database) 
as XML. You could want to nest SAXLets like this:
<datamodel:get-person>
  <name><request:get-parameter name="person-name"/></name>
</datamodel:get-person>
So the inner SAXLet has to be processed first and the result it is passed to 
the outer one.

Maybe conditionals could be realized this way:
<utils:choose>
  <select><request:get-parameter name="test"/></select>
  <when test="xy">
	Value xy is not allowed.
  </when>
  <otherwise>
  	You've chosen <request:get-parameter name="test"/> but this
	won't work because you cannot mix content and elements :-(
  </otherwise>
</utils:choose>

> > An optional mapping could be cool because the build-in mapping is not
> > always optimal. I think of simple methods returning a scalar or an array
> > where you don't want tag names like
> > <test:get-elements>1</test:get-elements>
> > <test:get-elements>2</test:get-elements>
> > <test:get-elements>3</test:get-elements>
> > to be generated. But one could also call element("element", value) in a
> > loop easily so maybe that's not really a problem.
>
> The scalar results may be useful (and I agree with your second email: the
> enclosing elements for scalar results should probably done away with),
> regarding the arrays I'm not so sure. The reason I implemented the array
> style is that one can access standard bean getters which return arrays this
> way. I agree that in order to make this feature really useful, a
> configurable mapping would be ideal.

That's what I wanted to say. Castor does actualy something similar
http://castor.exolab.org/xml-mapping.html.

> Joerg Henne
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org

-- 
Stefan K�hler
mailto:stefan.koehler@interface-projects.de

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: [C2 proposal] Alternative to XSP

[Davanum Srinivas <di...@yahoo.com>]

Joerg,

After thinking a bit more, i have a Question. Can you make it possible to mix and match regular
XSP logicsheets with SaxLet's? 

In other words, I want to be able to implement a logicsheet using SaxLet and use it in my XSP. For
example, You have a Request SaxLet, I want to use it in my XSP instead of using the Request Logic
Sheet.....Basically, if you can come up with a way for people to implement LogicSheets (that can
be used in regular XSP's) using SaxLet's it will be a real win-win situation. Developers will have
a choice to implement LogicSheets as usual by adding XSL's or by writing Java code.

Thanks,
dims

--- Joerg Henne <j....@levigo.de> wrote:
> Stefan,
> 
> Stefan Koehler wrote:
> > 
> > I tried your SAXLet example and I think it's exactly the thing I was 
> > looking for.
> 
> thannks for your feedback.
> 
> > The further point is that debugging saxlets is clearly _much_ easier than
> > debugging XSPs where you don't have a reference to the error line both at
> > compilation time and runtime unless you look at the generated code.
> 
> Yes, that was our main reason for looking into this new approach.
> 
> > Developing saxlets your favourite java development entvironment ensures that
> > they are syntacticaly correct and runtime errors could produce a readable
> > stacktrace. (At the moment, they don't because the stacktrace is not logged...)
> 
> True, the exception handling is currently sub-par. It's currently high on my
> to-do list :-)
> 
> > > What they (currently) can't do:
> > >
> > > - they can't be nested within one another because the SAXLet processor
> > > doesn't know anything about the semantics of a SAXLet element. Thus
> > > contained SAXLet elements would simply be passed to the containing SAXLet
> > > element's method.
> > 
> > This is a serious restriction. Perhaps nesting could be realized by not passing
> > Configuration objects directly but a subclass which calls the SAXLet processor
> > for childs that reference SAXLet methods (only a thought).
> 
> I like the idea. It's similar to what JSP does and the need to pass this
> object can be determined by looking at the method's signature. However, I
> think the DefaultConfiguration has the restriction that it does not support
> element content and children at the same time. Therefore we'd need something
> else.
> 
> Do you have any ideas on the semantics of this approach? Doing thinks like
> mixing random XML with field data from an SQL query in a loop would be fairly
> straight forward (just making this up):
> 
>    <foo:execute-query id="some-people" sql="..." maxrows="10"/>
>    <foo:foreach-row query-id="some-people">
> 	<person>
> 		<firstname><foo:get-field name="firstname"/></firstname>
> 		<lastname><foo:get-field name="lastname"/></lastname>
> 	</person>
>    </foo:foreach-row>
> 
> But this could also be solved with simple XSLT operations. What more could
> there be?
> 
> > An optional mapping could be cool because the build-in mapping is not always
> > optimal. I think of simple methods returning a scalar or an array where you don't
> > want tag names like
> > <test:get-elements>1</test:get-elements>
> > <test:get-elements>2</test:get-elements>
> > <test:get-elements>3</test:get-elements>
> > to be generated. But one could also call element("element", value) in a loop
> > easily so maybe that's not really a problem.
> 
> The scalar results may be useful (and I agree with your second email: the
> enclosing elements for scalar results should probably done away with),
> regarding the arrays I'm not so sure. The reason I implemented the array style
> is that one can access standard bean getters which return arrays this way. I
> agree that in order to make this feature really useful, a configurable mapping
> would be ideal.
>  
> Joerg Henne
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
> 


=====
Davanum Srinivas, JNI-FAQ Manager
http://www.jGuru.com/faq/JNI

__________________________________________________
Do You Yahoo!?
Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger
http://im.yahoo.com

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: [C2 proposal] Alternative to XSP

[Joerg Henne <j....@levigo.de>]

Stefan,

Stefan Koehler wrote:
> 
> I tried your SAXLet example and I think it's exactly the thing I was 
> looking for.

thannks for your feedback.

> The further point is that debugging saxlets is clearly _much_ easier than
> debugging XSPs where you don't have a reference to the error line both at
> compilation time and runtime unless you look at the generated code.

Yes, that was our main reason for looking into this new approach.

> Developing saxlets your favourite java development entvironment ensures that
> they are syntacticaly correct and runtime errors could produce a readable
> stacktrace. (At the moment, they don't because the stacktrace is not logged...)

True, the exception handling is currently sub-par. It's currently high on my
to-do list :-)

> > What they (currently) can't do:
> >
> > - they can't be nested within one another because the SAXLet processor
> > doesn't know anything about the semantics of a SAXLet element. Thus
> > contained SAXLet elements would simply be passed to the containing SAXLet
> > element's method.
> 
> This is a serious restriction. Perhaps nesting could be realized by not passing
> Configuration objects directly but a subclass which calls the SAXLet processor
> for childs that reference SAXLet methods (only a thought).

I like the idea. It's similar to what JSP does and the need to pass this
object can be determined by looking at the method's signature. However, I
think the DefaultConfiguration has the restriction that it does not support
element content and children at the same time. Therefore we'd need something
else.

Do you have any ideas on the semantics of this approach? Doing thinks like
mixing random XML with field data from an SQL query in a loop would be fairly
straight forward (just making this up):

   <foo:execute-query id="some-people" sql="..." maxrows="10"/>
   <foo:foreach-row query-id="some-people">
	<person>
		<firstname><foo:get-field name="firstname"/></firstname>
		<lastname><foo:get-field name="lastname"/></lastname>
	</person>
   </foo:foreach-row>

But this could also be solved with simple XSLT operations. What more could
there be?

> An optional mapping could be cool because the build-in mapping is not always
> optimal. I think of simple methods returning a scalar or an array where you don't
> want tag names like
> <test:get-elements>1</test:get-elements>
> <test:get-elements>2</test:get-elements>
> <test:get-elements>3</test:get-elements>
> to be generated. But one could also call element("element", value) in a loop
> easily so maybe that's not really a problem.

The scalar results may be useful (and I agree with your second email: the
enclosing elements for scalar results should probably done away with),
regarding the arrays I'm not so sure. The reason I implemented the array style
is that one can access standard bean getters which return arrays this way. I
agree that in order to make this feature really useful, a configurable mapping
would be ideal.
 
Joerg Henne

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: [C2 proposal] Alternative to XSP

[Stefan Koehler <st...@interface-projects.de>]

 Hello Joerg,

just another thought about mapping. The results or SAXLet Methods returning a 
scalar String or Boolean could be inserted automaticaly as character section 
without an enclosing tag. So it's up to the user to name the enclosing tag like 
he/she wants.

-- 
Stefan K�hler
mailto:stefan.koehler@interface-projects.de

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: [C2 proposal] Alternative to XSP

[Stefan Koehler <st...@interface-projects.de>]

Hello Joerg,

I tried your SAXLet example and I think it's exactly the thing I was looking for.

> Due to the fact that the SAXLet
> approach works with generation as well as transformation, XSP and SAXLets
> can work together smoothly.
> Furthermore, SAXLets could help to homogenize the current C2 code-base by
> removing duplicate code. For instance, the LDAP- as well as the
> SQLTransformer go to great lengths to filter and parse the event stream.
> They could both be implemented more naturally as SAXLets while providing
> exactly the same functionality.

This is the main point where I see the great advantage of the saxlet approach. 
The best logicsheet is worth not much when you have to use another 
generator than serverpages for some reason. You cannot use the same 
functionality at the transformation layer unless you write a separate transformer.

The further point is that debugging saxlets is clearly _much_ easier than 
debugging XSPs where you don't have a reference to the error line both at 
compilation time and runtime unless you look at the generated code.
Developing saxlets your favourite java development entvironment ensures that 
they are syntacticaly correct and runtime errors could produce a readable 
stacktrace. (At the moment, they don't because the stacktrace is not logged...)

In contrast, omitting the "name" attribute to <xsp-request:get-parameter> from
the request taglib leads to the a not very informative exception like this:
Language Exception:org.apache.cocoon.components.language.LanguageException: 
Error compiling simple_xsp: Line 291, column 67: Missing term.

> - SAXLets can be customized via attributes (whole XML fragments, actually)
> passed from the calling page

Passing a Configuration object to the SAXLet methods sounds good because of 
type safe access with methods like 
getAttributeAsBoolean(name, defaultDefaultValue);

> What they (currently) can't do:
>
> - they can't be nested within one another because the SAXLet processor
> doesn't know anything about the semantics of a SAXLet element. Thus
> contained SAXLet elements would simply be passed to the containing SAXLet
> element's method.

This is a serious restriction. Perhaps nesting could be realized by not passing
Configuration objects directly but a subclass which calls the SAXLet processor 
for childs that reference SAXLet methods (only a thought).

> The ad-hoc nature of the mapping between OO and XML space used by the
> SAXLet approach can be seen as an advantage, as it renders a JSP TLD style
> descriptor unnecessary. However, it also makes it difficult to validate the
> tags and to provide semantics other than a simple replacement of the mapped
> element. Therefore I am currently pondering this option.

An optional mapping could be cool because the build-in mapping is not always 
optimal. I think of simple methods returning a scalar or an array where you don't
want tag names like
<test:get-elements>1</test:get-elements>
<test:get-elements>2</test:get-elements>
<test:get-elements>3</test:get-elements>
to be generated. But one could also call element("element", value) in a loop
easily so maybe that's not really a problem.

In general I have to say that I like the SAXLet approach very much and I'm 
looking forward to the SAXLet transformer.

Stefan K�hler

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: [C2 proposal] Alternative to XSP

[Joerg Henne <fa...@levigo.de>]

Davanum,

Davanum Srinivas wrote:
> 
> Sorry for the delay in replying to your e-mail. I really like the mapping 
> between OO space and XML space. For obvious reasons we cannot get rid of 
> XSP....But we can adopt your approach to some extent. 

Thanks for your feedback. Of course it is not my intent to replace XSP.
However, I think that an alternative solution for the linking between the two
spaces is a valuable addition to C2. Due to the fact that the SAXLet approach
works with generation as well as transformation, XSP and SAXLets can work
together smoothly.

Furthermore, SAXLets could help to homogenize the current C2 code-base by
removing duplicate code. For instance, the LDAP- as well as the SQLTransformer
go to great lengths to filter and parse the event stream. They could both be
implemented more naturally as SAXLets while providing exactly the same
functionality.

> Have you thought about XSPlets to implement LogicSheets? This is more like 
> the Tag Library approach in JSP 

SAXLets and JSP taglibs already share quite a few features. Regarding the list
of features on the page you mentioned:

- SAXLets can be customized via attributes (whole XML fragments, actually)
passed from the calling page
- SAXLets have access to the processing environment (request, response etc.)
- SAXLets can communicate with each other. All methods of one SAXLet share the
same instance, so they can "communicate" anyway. But also a SAXLet may
register itself with the objectModel so that others can access its
information.
- of course tey can modify the generated response
- they can encapsulate simple and complex behaviour, whatever this means :-)

What they (currently) can't do:

- they can't be nested within one another because the SAXLet processor doesn't
know anything about the semantics of a SAXLet element. Thus contained SAXLet
elements would simply be passed to the containing SAXLet element's method.

The ad-hoc nature of the mapping between OO and XML space used by the SAXLet
approach can be seen as an advantage, as it renders a JSP TLD style descriptor
unnecessary. However, it also makes it difficult to validate the tags and to
provide semantics other than a simple replacement of the mapped element.
Therefore I am currently pondering this option.

Joerg Henne

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: [C2 proposal] Alternative to XSP

[Davanum Srinivas <di...@yahoo.com>]

Joerg,

Sorry for the delay in replying to your e-mail. I really like the mapping between OO space and XML
space. For obvious reasons we cannot get rid of XSP....But we can adopt your approach to some
extent. Have you thought about XSPlets to implement LogicSheets? This is more like the Tag Library
approach in JSP (http://www.onjava.com/pub/a/onjava/2000/12/15/jsp_custom_tags.html)

Thanks,
dims

--- Joerg Henne <j....@levigo.de> wrote:
> Hi,
> 
> we all know and like XSP. However, we also know quite a few of its problems.
> Therefore I'd like to propose an alternative to XSP which may be, in many
> cases, a viable and much easier to use option.
> The basic idea has come up at least once on this list: perform a mapping
> between XML space and OO space like this:
> 
> - map an XML namespace onto a class which implements certain interfaces
> - map XML element names within the namespace onto method names
> - pass attributes and children of the mapped element to the method.
> 
> This mapping can either be performed in a generator or a transformer. Although
> the current implementation only supports the generator option, it already
> features a separation of the processing functionality into a separate class
> which makes the implementation of the transformer quite trivial.
> 
> --- The implementation in detail:
> 
> As the classes onto which the XML namespaces are mapped act as delegates in
> the production of XML fragments, they have been called "SAXLets".
> Consequently, the generator is called "SAXLetGenerator". The SAXLetGenerator
> uses a SAXLetProcessor as a delegate for the processing.
> 
> The SAXLets must be implementations of avalon Components with an additional
> interface SAXLet. The SAXLet interface is currently only a marker-interface
> and it has to be seen, if it makes sense to get rid of it in the future.
> 
> SAXLets may implement any of the Avalon lifestyle and life-cycle interfaces to
> control their management and two more interfaces to control their
> configuration:
> - SAXLets implementing XMLProducer will be passed a reference to an
> XMLConsumer
> - SAXLets implementing SitemapModelComponent will be set up like other
> SitemapModelComponents
> During one processing session, only on instance of each SAXLet will be created
> (i.e. retrieved from the ComponentSelector).
> 
> The mapping of element names to method names is subject to the following
> rules:
> - some-element becomes someElement
> - ELEMENT becomes eLEMENT
> The mapping is currently far from being fool-proof and probably has to be
> improved. Methody may be declared without parameters, or as takin an Avalon
> Configuration. In the latter case, the SAXLet processor will pass attributes
> and children of the mapped element to the method in the form of the
> Configuration.
> 
> It's quite obvoius that the SAXLetProcessor uses reflection to lookup and
> invoke the SAXLet methods. Now, I know your qualms about reflection, however,
> I've come to the comclusion that reflection is quite "fast enough":
> - It's the lookup of the method which takes a huge about of time. The
> invocation using Method.invoke() is much faster. Therefore the implementation
> caches the looked-up methods.
> - Benchmarks show, that dynamic invocation is (sxcluding the lookup) still
> about 30 times slower (on JDK 1.3) than static invocation. However, to put
> this into perspective, I've found my machine (900MHz, intel) to take roughly
> 1us per dynamic invocation. Or, in other words, if a page contains 10 SAXLet
> elements, the machine will spend about 10s for 1M-hits on the dynamic
> invocation. I think that's a reasonable figure.
> 
> Methods may produce output three ways:
> - A method may return an scalar Object. In this case the Object will be
> converted to String and, wrapped in an element of the same name as the
> invoking element, and sent down the pipeline.
> - A method may return an array of Objects. This is the same as the scalar
> case, just that ther will be an element with content for each array element.
> - A method may produce SAX events on it's own. In this case the SAXLet must
> implement XMLProducer, so that the reference to the consumer is available. The
> XML events will be filtered through a XMLFragmentCompleter (a new utility
> class) which makes sure that the XML is well-formed even in the case of
> premature returns.
> 
> Excetions thrown by the SAXLet methods are caught, logged, and re-trown
> wrapped in SAXExceptions.
> 
> The implementation comes with a very simple example, the RequestSAXLet, which
> re-implements the functionality of the request logicsheet as a SAXLet. The
> sample has ist's own sub-sitemap, the mounting of the sub-sitemap is up to
> you.
> 
> --- Future stuff and RT
> 
> Obviously, XSP can do a few things that SAXLets can't do, e.g. iteration and
> conditional processing of the input. However, one could argue that the need
> for iteration or conditional processing is an indication for a possible mixing
> of concerns. On the other hand, at least iteration and conditionals could be
> implemented, albeit in a less natural way than the simple delegation of the
> XML production.
> 
> Currently, the generator does not support caching. However, SAXLets could very
> well implement Cacheable so that the cacheable descision could be delegated to
> the SAXLets. We intend to add this RSN.
> 
> An additional performance improvement for the Generator can be achieved by
> caching the input events together with the references to the SAXLets and their
> methods, in order to get rid of the parsing of the input and lookup of the
> namespaces that is currently necessary.
> 
> --- 
> 
> I suppose that some of you will hate the SAXLet approach as it is quite
> incompatible with XSP and breaks all the current value-added functionality
> (logicsheets). But please let your comments roll in. 
> 
> Joerg Henne

> ATTACHMENT part 2 application/x-zip-compressed name=saxlet.zip
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org


=====
Davanum Srinivas, JNI-FAQ Manager
http://www.jGuru.com/faq/JNI

__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org