cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Don Brown <donald.br...@gmail.com>
Subject Re: JS versus Java [was Re: FOM inconsistency (was Re: [VOTE] Unrestricting the FOM)]
Date Sun, 27 Feb 2005 19:07:58 GMT
On Sun, 27 Feb 2005 14:16:23 +0100, Sylvain Wallez <sylvain@apache.org> wrote:
<snip />
> This is actually similar to ServletRequest.getParameterMap() in servlet
> 2.4 which we do not have on our Request interface. But we should not
> introduce special wrappers for Map as proposed recently by the
> Struts-flow guy (need to make an answer and point him to this
> discussion) as we would just be moving the problem one level deeper:
> what would "map.size" mean if it contains a "size" entry?

As I see it, there are two ways to solve this problem:

1. Use ordering ie function, property so function calls are used first
(or vice versa)
2. Use a special function prefix to ensure functions are called.  In
my implementation, I have an optional "fn_" which can be used to
ensure you are calling a function and it cannot be overridden.  Any
prefix should, of course, be able to be turned off or changed.

That said, this is not an issue for the wrapper around List.  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).

Don

> 
> > <SNIP/>
> >
> >> The multiple expression languages are also a problem, especially if
> >> you consider that each one has its own preferred way of expressing
> >> things. Starting from one single class, you have to learn not only
> >> the standard mapping to Java objects provided by each language, but
> >> also all the different specific mappings provided for each of the
> >> object model objects. IMO a nightmare for users.
> >>
> > Exactly, that's why I still think we should use one expression
> > language :)
> 
> I would love to, but really don't think this is realistic. We need one
> language for objects and one language for XML documents. JXPath can
> theoretically handle both, but using XPath when the controller and
> business logic use objects is very unnatural...
> 
> > Now, before we start some votes on something that has perhaps not
> > properly discussed before, we should really take some time and think
> > about:
> >
> > 1) What the best way of accessing the information is
> > 2) Then: what this means in term of compatibility and migration
> > 3) Then: provide an easy way for users to update their code (if required)
> >
> > But imho we shouldn't mix these concerns.
> >
> > For 1:
> > I think an explicit addressing is the way to go, so e.g. you use
> > getParameter("name") in Flow and request.parameters.name in jxtg and
> > so on. In my understanding using object in flow and in Java should be
> > very similar as in many cases you are using both worlds and it's a
> > nightmare to switch between different apis.
> 
> IMO, we should be able to use the same dotted syntax in flow and jxtg.
> And we can decide that this syntax is JS, which may solve many problems
> by using a single scripting language everywhere.
> 
> But, again, I really think we should also have XPath in jxtg as well.
> Maybe as a function-like syntax such as "xpath(doc, '/a/b/c')", which
> would answer your concern of having a single expression language.
> 
> Sylvain
> 
> --
> Sylvain Wallez                                  Anyware Technologies
> http://www.apache.org/~sylvain           http://www.anyware-tech.com
> { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
> 
>

Mime
View raw message