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: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
--
Stefan Köhler
mailto:[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
