cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Koehler <>
Subject Re: [C2 proposal] Alternative to XSP
Date Fri, 31 Aug 2001 14:42:51 GMT

> 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:

  Some content as argument <othersaxlet:method/> Whatever else.

had to be substituded with something like that:

  	<util-saxlet:part>Some content as argument</util-saxlet:part>
	<util-saxlet:part>Whatever else.</util-saxlet:part/>


> 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:
  <name><request:get-parameter name="person-name"/></name>
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:
  <select><request:get-parameter name="test"/></select>
  <when test="xy">
	Value xy is not allowed.
  	You've chosen <request:get-parameter name="test"/> but this
	won't work because you cannot mix content and elements :-(

> > 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

> Joerg Henne
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, email:

Stefan Köhler

To unsubscribe, e-mail:
For additional commands, email:

View raw message