cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylv...@apache.org>
Subject Re: JS versus Java [was Re: FOM inconsistency (was Re: [VOTE] Unrestricting the FOM)]
Date Sun, 27 Feb 2005 13:16:23 GMT
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!!
>>
>> 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.
>>
> Yepp - I totally agree - it's absolutely not visible anymore what 
> "request.remoteUser" really means - it's hard to understand and 
> maintain this code.
>
>> 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 }


Mime
View raw message