cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Davanum Srinivas <d...@yahoo.com>
Subject Re: [C2 proposal] Alternative to XSP
Date Fri, 31 Aug 2001 12:09:23 GMT
Joerg,

After thinking a bit more, i have a Question. Can you make it possible to mix and match regular
XSP logicsheets with SaxLet's? 

In other words, I want to be able to implement a logicsheet using SaxLet and use it in my
XSP. For
example, You have a Request SaxLet, I want to use it in my XSP instead of using the Request
Logic
Sheet.....Basically, if you can come up with a way for people to implement LogicSheets (that
can
be used in regular XSP's) using SaxLet's it will be a real win-win situation. Developers will
have
a choice to implement LogicSheets as usual by adding XSL's or by writing Java code.

Thanks,
dims

--- Joerg Henne <j.henne@levigo.de> wrote:
> 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: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
> 


=====
Davanum Srinivas, JNI-FAQ Manager
http://www.jGuru.com/faq/JNI

__________________________________________________
Do You Yahoo!?
Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger
http://im.yahoo.com

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message