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