Yepp - I totally agree - it's absolutely not visible anymore what "request.remoteUser" really means - it's hard to understand and maintain this code.
And that's what I call, maybe not adequately, "inconsistencies". Consider the JS wrapper for the request object. It has a "remoteUser" property because of the request.getRemoteUser() method. Now what happens if "http://foo/bar?remoteUser=root"; is called? Your application is fooled in believing that a super user issued the resquest!!
The result of this is that you always have to refrain using the properties in favor of method calls in order to be really sure of what data you access, and therefore loose the apparent simplicity of properties.
An acceptable JS wrapper, less verbose that the standard Java/JS mapping would be one that clearly separates the various property spaces, e.g. "request.parameters.foo". But implementing this causes other problems (see below).
Can you expand on this please?
> <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 :)
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.
Carsten
-- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
