Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (hermes.apache.org: domain of peter.hunsberger@gmail.com
 designates 64.233.184.200 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references;
        b=ZGc2tUIYu0FLXDzaHxJgrCwmJhm2f1krTO9RGJbOAbbFzWBjWjK1V73BxtO1ijTnfJfySPdLjOyTDQsUqL8vU0/aa4S5uJbB10l7BcZxtCAfNJuOD1tzpW1YAS6ub7Fa2LfattFPz20CsE/oqUVMo/tssN3nym09yrZitFH4cmw=
Message-ID: <cc159a4a0503071050507b4cc@mail.gmail.com>
Date: Mon, 7 Mar 2005 12:50:25 -0600
From: Peter Hunsberger <peter.hunsberger@gmail.com>
Reply-To: Peter Hunsberger <peter.hunsberger@gmail.com>
To: dev@cocoon.apache.org
Subject: Re: [RT] A Unified Environment Model?
In-Reply-To: <422C9B2C.5050205@nada.kth.se>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <42239FC2.3020503@nada.kth.se> <4226F189.30008@apache.org>
	 <4226FD84.1080204@nada.kth.se> <4227168E.4070203@apache.org>
	 <4227E3B0.1080806@reverycodes.com> <422825ED.5090901@apache.org>
	 <cc159a4a05030408047698ac01@mail.gmail.com>
	 <42298F8A.6040806@nada.kth.se>
	 <cc159a4a0503070842277c7c1f@mail.gmail.com>
	 <422C9B2C.5050205@nada.kth.se>

On Mon, 07 Mar 2005 19:19:24 +0100, Daniel Fagerstrom
<danielf@nada.kth.se> wrote:
> Peter Hunsberger wrote:

<snip>older conversation</snip>
> 
> >>>
> >>>
> >>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.

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

What's the reason for using script access over anything else?

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

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

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.

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!

> 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 ???

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

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

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

Yah, don't hold your breath....  ;-(

<snip>old wrap up</snip>

-- 
Peter Hunsberger