Carsten Ziegeler wrote:
Sylvain Wallez wrote:
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!!Yepp - I totally agree - it's absolutely not visible anymore what "request.remoteUser" really means - it's hard to understand and maintain this code.
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?
If we consider the request object, we have 3 property spaces:
1 - the JavaBean property space, which exposes e.g. "request.getRemoteUser()" as "request.remoteUser"
2 - the parameter space, accessed using "request.getParameter("foo")"
3 - the attribute space, accessed using "request.getAttribute("bar")".
I agree that using method call notation is more verbose than using the dotted property notation. The problem is that currently we have either the second or third spaces merged with the first one, hence the problems examplified with remoteUser. Worse, space 3 is merged with space 1 on session and context, and it's space 2 that is merged with space 1 on the request. Confusing.
So a way to still benefit from the simple dotted notation is to have each property space attached to a different object. The first space is kept attached to the request object itself (normal Java to JS mapping), and we can introduce additional JS properties that hold the other property spaces.
Hence "request.parameters.foo" and "request.attributes.bar". The additional "parameters" and "attributes" property allow to clearly disambiguate what property space we're referring to.
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?
<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 }
