cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Don Brown <>
Subject Re: JS versus Java [was Re: FOM inconsistency (was Re: [VOTE] Unrestricting the FOM)]
Date Sun, 27 Feb 2005 22:28:45 GMT
On Sun, 27 Feb 2005 23:15:00 +0100, Sylvain Wallez <> wrote:
<snip />
> The simple fact that we have to elaborate such strategies IMO reveals
> that there's a problem. This problem comes from the fact that a dynamic
> property space (request parameters, map entries, etc) is merged with a
> static property space (coming from the Java object), and that's why I
> proposed an additional static property to hold the dynamic space.
> In the case of request, this leads to both "request.parameters" and
> "request.attributes" as we have two dynamic property spaces.
> In the case of Map, this could be "map.entries", i.e. you would write
> "" instead of map.get("foo"). But we can also consider
> that Map is of a special kind as it is nothing but a dynamic property
> space for Java. In that very particular case, we could reverse the
> scheme and have the dynamic space be the main property space (i.e.
> "") and have the actual Map methods be accessed through a single
> special property, e.g. "map.__obj__.size()". Mmmh...

I really like the dynamic property spaces for request attributes in
parameters, but when talking about a Map, honestly, I don't think
there is a clean solution.  The former ".entries" idea is even more
verbose than the regular get() method, and the latter strategy is
similar to the "fn_" prefix but with the additional (admittedly
infrequent) problem of retrieving a property called "__obj__", not to
mention being more difficult to access extended properties and

> >That said, this is not an issue for the wrapper around List.
> >
> Yes, because a List's dynamic property space is defined by numbers (the
> index), and there is therefore no overlapping between the regular
> object's properties and the ones added by the special wrapper.
> >I wrote
> >a framework so you can add properties and methods to Java API's in a
> >generic way, and I use this to, among other things, add a "length"
> >property to any object that implements Collection to make it more
> >consistant with what one would expect to use with a JS array.  My
> >favorite use of extension functions is to add closure functions such
> >as File.eachLine(func).
> >
> >
> That's groovy, in all meanings of it ;-)

Indeed as that was the inspiration - wanting the nice Java integration
and extensions of Groovy but with a mature, continuations-capable
scripting language.  As I mentioned, I'm writing this keeping it clean
of Struts and chain constructs so it could be used in Cocoon if you
folks were interested, by moving it to a commons project.


> Sylvain
> --
> Sylvain Wallez                                  Anyware Technologies
> { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

View raw message