cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: [RT] A Unified Environment Model?
Date Mon, 07 Mar 2005 18:19:24 GMT
Peter Hunsberger wrote:

>On Sat, 05 Mar 2005 11:52:58 +0100, Daniel Fagerstrom
><> wrote:
>>Peter Hunsberger wrote:
>>>This is more of a RT than anything concrete for or against the ideas
>>>given so far.
>>>As I follow this discussion it keeps striking me that we're
>>>more-or-less reinventing resolvers and sources at a slightly lower
>>>level.  At one level, people need:
>>>   protocol://x/y/z
>>>to resolve to some XML/SAX stream fragment. Now we want
>>>  module.x.y.z
>>>to resolve to something that isn't always XML but can be used to
>>>create a SAX stream or can be traversed with some kind of expression
>>Sources are designed for giving access to streams (and due to eficciency
>>reasons SAX streams) and the "object accessors" are intended to give
>>access to script friendly POJOs. The streams and SAX streams are
>>consumed by parsers or event handling code, while the POJOs are accessed
>>by ELs and scripting languages that typically use reflection mechanisms.
>>That is quite a large difference.
>>Even if there are similarities at a more abstract level I don't see what
>>we would gain by trying to merge the concepts at the implementation level.
>It's not so much a merge as a change in mind set: don't promote script
>access to POJO's at all;
The main use case is to unify script access to environment data like the 
request object.

> instead encourage production of XML via POJO
>wrappers feeding XSLT.
The "object accessors" are used in a configuration file to put together 
a script OM, like e.g. the FOM. If we have such script friendly OMs it 
would be quite easy to build a XML source based on that by using e.g. 
Castor. IMO the ideas discussed in this thread will make it easier to do 
what your asking for.

>>>So on one hand, we've got source resolvers and xpath and on the other
>>>hand we've got factories (hidden or not) resolving to object modules
>>>and some expression languages.
>>>I can't help but have the feeling that if XSLT  was easy we wouldn't
>>>be having this discussion at all.  Stefano once proposed an alternate
>>>XSLT syntax, but I think the issues of understanding a declarative
>>>language wouldn't go away.
>>XSLT is my number one tool for building Cocoon based webapps, so what
>>you suggests certainly doesn't apply to me. IMO the main reason that we
>>are not using XSLT for accessing object graphs is that current XSLT
>>implementation not are particullary well suited for solving that task.
>>XSLT as language could certainly be used for it, but the current
>>implementations are specialized for being efficient for SAX inputs. And
>>rather hard to use for anything else.
>Hmm, I don't see this. Can you explain more what problems you run
>into?  We build very complex graph resolution logic into XSLT. 
>Properly used it seems much better than Java or a scripting language
>for graph traversal? (and I've written code in many, many languages
>over the years...)
The problem is not graph traversal. The problem that I talk about is, 
that for many applications you have a rather large Java bean structure 
e.g. the FOM and you are only going to access a small part of it. 
Serializing the whole Java object to SAX and then select the few data 
that you actually needed in XSLT becomes ineficient.

A better solution is to use a lazy DOM adapter for the Java object that 
use reflection on the part of Java data structure that are needed 
instead of on all of it. You can find details about this approach in the 
"[RT] the quest for the perfect template language" and follow up 
threads. Now a problem with such an approach is that there are no, 
AFAIK, good lazy DOM adapters. And AFAIU Saxon and Xalan doesn't handle 
DOM input as efficient as one would hope, they build internal models of 
the DOM even if it shouldn't be needed. So in the end, according to my 
experience (I spent a lot of time on the task two years ago), it is much 
more work than it seem like and its questionable if the result would be 
that good.

Compared to that having a minimal template language (e.g. JXTG) that use 
an EL is much simpler way to solve most of the use cases.

If someone feel like making it easier to use XSLT as a template language 
I'm all for it, but I have lost the interest in doing it my self.

>>>Personally, I wonder if any of what is being discussed is really
>>It should be clear be clear from this thread what use cases we have in
>>mind. If you have better suggestions on how we can achieve them, please
>>go ahead and tell us.
>Actually, the real underlying use-cases for script based EL's isn't
>really that clear. The best I can come up with is the conditional
>production of some XML/SAX fragment that is expensive to produce (so
>you want to avoid it if possible).  Even then, I can't see a real
>reason why branching flow with EL works better than branching flow
>with conventional pipelines (and perhaps some I/O module replacement).
No, we are not discussing anything like that. What we are trying to 
solve is that you have different models for accessing basic environment 
data in the sitemap on hand and in flow and JXTG on the other hand, we 
want a common reusable model, that's all.

Using JS as standard EL in Cocoon is Sylvain's idea so he can give a 
much better description of the advantages than I can (especially as I'm 
not completely convinced yet ;) ). But I'm quite certain that he doesn't 
have something like what you describe in mind.

>Certainly Web services requires no POJO scripting, SAX production to a
>standard pipelines works just fine?  (Though flow script helps).
The object accessors and the "unified environment model" have nothing to 
do with my RTs about how to simplify Cocoon web service orchestration 
that I have discussed in other threads (Terms like environment are far 
to overloaded :/ )

>>>I'd love to see the Cocoon community put a stake in the
>>>ground and build a good set of XSLT authoring tools and XSLT function
>>>and document support capabilities and say "the way to data
>>>manipulation and transformation with Cocoon is XSLT!"
>>So would I. But my itch is not strong enough for actually make it
>>happen, is yours?
>Well, that's the thing; we already have this.  You don't really have
>to add anything to Cocoon to make it happen...  A POJOSource/Generator
>pair that took any random POJO and used introspection to generate a
>SAX stream might be fun, but I can't see the need;  getting SAX out of
>any POJO isn't really hard.  Having a said that, there are things that
>Cocoon could use to make this easier for the average user.
>We've got a solution that works for us. Unfortunately, our institution
>has a problem contributing directly to open source projects. 
>Basically, we're non-profit and one of the ways we get funding is by
>licensing our innovations back to interested parties.  As a result
>I've not had any luck getting permission to contribute directly back
>to any Open Source project.  The  best I can do is random code
>fragments in the mailing list and ideas...
I see. Even if you can't contribute code it would be much easier for 
people, how are able to contribute coding, to evaluate you ideas if you 
wrote something more like a design document.

>>>Given that doesn't seem likely to happen,
>>You can make it happen if you want to.
>>>I guess the only thing I can
>>>suggest here is that everyone should take a step back and make sure
>>>the existing Cocoon machinery for source resolving and xpath traversal
>>>isn't re-usable in some way before inventing anything new...
>>AFAIK there is no existing xpath traversal machinery in Cocoon that we
>>could reuse. Part of the proposal is about having such a reusable EL
>>mechanism based on the pluggable ELs from template, and about making the
>>"script environment" more reusable.
>I can't really see a good way to use the existing code base either,
>but I threw the idea out since there might be others who have more
>experience with the Cocoon internals who might think of something.


View raw message