cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Hunsberger <peter.hunsber...@gmail.com>
Subject Re: [RT] A Unified Environment Model?
Date Fri, 04 Mar 2005 16:04:13 GMT
On Fri, 04 Mar 2005 10:10:05 +0100, Sylvain Wallez <sylvain@apache.org> wrote:
> Vadim Gritsenko wrote:
> 
> > Sylvain Wallez wrote:
> >
> >> Daniel Fagerstrom wrote:
> >>
> >>> Sylvain Wallez wrote:
> >>>
> >>>> Isn't it too restrictive compared to the variety of what modules do?
> >>>
> >>> Don't think so (returning an Object does not to restrict things that
> >>> much ;) ), but I haven't thought in detail about all modules, any
> >>> examples where it wouldn't work?
> >>
> >> E.g. those modules that do some xpath extraction on XML data. But
> >> maybe that isn't a problem if we consider my JS-as-the-only-EL
> >> proposal as we could write 'xpath(om.xmlmodule, "/path/to/element[1]")'.
> >
> > IMHO, there is no point in such input modules anymore. All you need is
> >
> >   * JS and EL firendly object model with "object factories"
> >     ("modules" is banned word)
> 
> Not sure object _factories_ is the right word either, as they don't
> create the object, but give access to them (creation is a particular
> case of giving access). Something like "object accessor" would be better.
> 
> >   * Support of the EL in the sitemap
> >
> > Once these two points are here, all existing input modules can be
> > (deprecated and) removed. And all that they did can be then done in
> > the sitemap with EL:
> >
> >   {/request/attributes/user}
> >
> > WDYT?
> 
> Kewl. This will bring to Cocoon both an improved consistency and an
> improved expressiveness because of the genearlized EL.

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.

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.

Personally, I wonder if any of what is being discussed is really
necessary; 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!"

Given that doesn't seem likely to happen, 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...

-- 
Peter Hunsberger

Mime
View raw message