Re: [RT] A Unified Environment Model?

[Daniel Fagerstrom]

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

Peter Hunsberger wrote:
<snip/>
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.

<snip/>
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?
No.
 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 
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105029949912114&w=2.

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"
http://marc.theaimsgroup.com/?t=104930795600004&r=1&w=2 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
necessary;
         

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

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.
<snip/>
/Daniel