cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Hunsberger <>
Subject Re: [RT] A Unified Environment Model?
Date Mon, 07 Mar 2005 16:42:27 GMT
On Sat, 05 Mar 2005 11:52:58 +0100, Daniel Fagerstrom
<> wrote:
> Peter Hunsberger wrote:
> <snip/>
> > 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
> > language.
> 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; instead encourage production of XML via POJO
wrappers feeding XSLT.

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

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

Certainly Web services requires no POJO scripting, SAX production to a
standard pipelines works just fine?  (Though flow script helps).

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

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

Peter Hunsberger

View raw message