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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
