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 19:56:42 GMT
Peter Hunsberger wrote:

>On Mon, 07 Mar 2005 19:19:24 +0100, Daniel Fagerstrom
><> wrote:
>>Peter Hunsberger wrote:

>That's not a use case, that's a technical usage example (at best).
>We've already got unified access to environment data like the request
>object.  For example, the RequestGenerator...
You can use the RequestGenerator for accessing request data in a 
pipeline, but you can't use it (in an efficient way) for accessing 
request data in the sitemap, or in flowscripts, or in templates (for 
those who don't like XSLT).

>What's the reason for using script access over anything else?
With script access I meant reflection friendly access, i.e. packaging 
the object in such a way that it is easy to access for a script 
language, and expression language, a Java->XML mapper etc.

>>>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.
>I actually believe that much of what's being discussed is something
>good, but I also wonder if some of it's going beyond what's necessary.
> I can already pick up a POJO via script.  But even given that,
>slightly better ways of getting at the Cocoon internals in a
>standardized way makes sense.  Extending this into a some kind of
>common templating languages is where I start to wonder exactly what
>the benefit is...
Are you refering to the idea of having a configurable OM? I found it 
initially to be FS, but everybody else that was involved in the 
discussion wanted it, so I based my proposal on it. Carsten wanted it 
for giving access to some portal specific data for portal use whithout 
needing to have it everywhere else. Having a minimal OM could also make 
sense for making things cacheable.


>>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.
>Have you actually done the measurements?

>  If so I'd be interested. 
>Walking a large POJO, generating a couple of hundred SAX events and
>catching one or two of them in a SAX filter doesn't strike me as
>having much worse impact than instantiating a scripting engine and
>then using that (indirectly) to access the data.
JXTG (as well as the new refactored one), compiles the template to an 
internal thread safe format once. The expressions are also compiled 
once. Chris Oliver published some benshmarks that showed that it seemed 
to be an efficient apporoach

Also in the configurable OM approach we discuss, the "skeleton" of the 
OM will be singlethreaded and constructed once.

>We in-fact do the former.  Caching on the SAX streams keeps things
>quickly at hand for the XSLT's that need them and everything runs in
>sub-second response time. We also generate some very large SAX streams
>into Saxon based XSLT pipelines where probably 3/4's (if not more) of
>the input is discarded by the end of the pipeline.  This also runs
>sub-second.  We're talking 100's of users, not 1000's but the issues
>that would stop us from going to more users aren't SAX generation and
>XSLT on any of the Cocoon related environment data or similar!
In most webapps it is the backend rather than the Cocoon web gui that is 
the limiting factor. But in some applications Cocoon prestanda counts as 
well, so it seem reasonable that we care about it.

>>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.
>AFAIK Saxon doesn't create a DOM model in a pure SAX XSLT pipeline ???
It creates a DOM like internal model. But that wasn't what I discussed, 
the main thing is that Xalan and Saxon, AFAIK don't are particullary 
efficient when you have DOM input.

>>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.
>I can understand...  
>>>>>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.
>I'd still like to see some real use cases .... 
1. Making it easier to learn Cocoon for new users by providing *one* OM 
that is used everywhere, instead of having one style from input modules, 
another in flowscript, still another through the 
RequestTemplateGenerator, still another in XSP and so on.

2. Making it easier to maintain and develop Cocoon by providing a common 
mechanism, tools, APIs for something that is used in many places within 
Cocoon and hasn't been standardized yet.

You are not going to be able to do something new that wasn't possible 

>>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.
>I'm sort of ok with the JS model, though I'm also not completely clear
>on what it's all going to provide me (I do want access to all of the
>Cocoon environment in flow script).  It's the JXTG and related
>machinery that starts to seem like excess to me...
To me also, I would prefer a strict read only EL in JXTG.



View raw message