Return-Path: 
 <cocoon-dev-return-16656-apmail-xml-cocoon-dev-archive=xml.apache.org@xml.apache.org>
Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org
Received: (qmail 39917 invoked by uid 500); 31 Aug 2001 14:42:55 -0000
Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:cocoon-dev-help@xml.apache.org>
list-unsubscribe: <mailto:cocoon-dev-unsubscribe@xml.apache.org>
list-post: <mailto:cocoon-dev@xml.apache.org>
Reply-To: cocoon-dev@xml.apache.org
Delivered-To: mailing list cocoon-dev@xml.apache.org
Received: (qmail 39847 invoked from network); 31 Aug 2001 14:42:54 -0000
From: Stefan Koehler <stefan.koehler@interface-projects.de>
To: cocoon-dev@xml.apache.org
Subject: Re: [C2 proposal] Alternative to XSP
Date: Fri, 31 Aug 2001 16:42:51 +0200
X-Mailer: KMail [version 1.1.99]
Content-Type: text/plain;
  charset="us-ascii"
References: <20010829103945.87261.qmail@web12801.mail.yahoo.com>
 <01083011480102.00795@pitti> <3B8E7BA5.91720C43@levigo.de>
In-Reply-To: <3B8E7BA5.91720C43@levigo.de>
MIME-Version: 1.0
Message-Id: <01083116425104.00795@pitti>
Content-Transfer-Encoding: 8bit
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

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