Re: JS versus Java [was Re: FOM inconsistency (was Re: [VOTE] Unrestricting the FOM)]
On Sun, 27 Feb 2005 23:15:00 +0100, Sylvain Wallez <[EMAIL PROTECTED]> wrote: > 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 > "map.entries.foo" 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. > "map.foo") 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 functions. > > >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. Don > > Sylvain > > -- > Sylvain Wallez Anyware Technologies > http://www.apache.org/~sylvain http://www.anyware-tech.com > { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects } > >
Re: JS versus Java [was Re: FOM inconsistency (was Re: [VOTE] Unrestricting the FOM)]
Don Brown wrote: On Sun, 27 Feb 2005 14:16:23 +0100, Sylvain Wallez <[EMAIL PROTECTED]> wrote: 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. 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 "map.entries.foo" 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. "map.foo") and have the actual Map methods be accessed through a single special property, e.g. "map.__obj__.size()". Mmmh... 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 ;-) Sylvain -- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: JS versus Java [was Re: FOM inconsistency (was Re: [VOTE] Unrestricting the FOM)]
As an aside, I thought more about it and decided approach #1 was better and less confusing so I switched Struts Flow to that. I still believe the map wrapper provides value as it works great for quick lookups and for..in usage. It also allows for the aforementioned extensions like a "length" property. Don On Sun, 27 Feb 2005 11:07:58 -0800, Don Brown <[EMAIL PROTECTED]> wrote: > On Sun, 27 Feb 2005 14:16:23 +0100, Sylvain Wallez <[EMAIL PROTECTED]> wrote: > > > 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 > > > > > > > > > > > >> 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 } > > > > >
Re: JS versus Java [was Re: FOM inconsistency (was Re: [VOTE] Unrestricting the FOM)]
On Sun, 27 Feb 2005 14:16:23 +0100, Sylvain Wallez <[EMAIL PROTECTED]> wrote: > 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 > > > > > > >> 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 } > >
Re: JS versus Java [was Re: FOM inconsistency (was Re: [VOTE] Unrestricting the FOM)]
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? 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 }
Re: JS versus Java [was Re: FOM inconsistency (was Re: [VOTE] Unrestricting the FOM)]
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? > 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/
Re: JS versus Java [was Re: FOM inconsistency (was Re: [VOTE] Unrestricting the FOM)]
Christopher Oliver wrote: Sorry to pick on Sylvain again, but he consistently exhibits a common behavior of Java programmers with respect to JavaScript. Because JS syntax is so similar to Java they seem to feel a JS API is somehow "better" the more it resembles what it would look like if it was written in Java. The "special wrapper" objects in the FOM served two purposes: 1) The enforced the FOM contracts which were voted on by the Cocoon community (note that although I implemented it I did _not_ define those contracts). 2) They made the underlying Cocoon Java API (Request, Session, etc) easier to access in JS (and in Jexl whose syntax is identical to JS). It should be obvious by looking at the history of JSP (which migrated from plain Java to the JSTL EL (implementd by Jexl). that a JS like approach can be preferable to Java in some cases. Opinions may vary, but to me JS is _actually_ a different language than Java and and an API that is provided in both languages should not be required to be identical in every respect (e.g. JavaFlow versus JS flow, Java DOM versus JS DOM, etc). Sylvain describes these differences as "inconsistencies", however I rather regard them as appropriate differences given the target languages (which in the case of JS will be appreciated by experienced JS programmers). At any rate, I fail to understand how a massively non-backward compatible change can be made which was not even relevant to the subject voted on. yes please, can we discuss this again (with a final vote) as I'm not really convinced about the pros of this change. As I understand it there was a vote to "unrestrict" the FOM, thereby removing the contracts from (2) above. AFAIK this could have been implemented easily without causing backward incompatibility in accessing the FOM from JS/Jexl/JXPath. This change forces our users to rewrite their templates too?!?!? My $0.02, Thanks you as I would have overlooked this ... (too much traffic on this list) BTW, nice to see you back from time to time :-) -- Reinhard Pötz Independant Consultant, Trainer & (IT)-Coach {Software Engineering, Open Source, Web Applications, Apache Cocoon} web(log): http://www.poetz.cc
Re: JS versus Java [was Re: FOM inconsistency (was Re: [VOTE] Unrestricting the FOM)]
Christopher Oliver wrote: Sorry to pick on Sylvain again, but he consistently exhibits a common behavior of Java programmers with respect to JavaScript. Because JS syntax is so similar to Java they seem to feel a JS API is somehow "better" the more it resembles what it would look like if it was written in Java. The "special wrapper" objects in the FOM served two purposes: 1) The enforced the FOM contracts which were voted on by the Cocoon community (note that although I implemented it I did _not_ define those contracts). 2) They made the underlying Cocoon Java API (Request, Session, etc) easier to access in JS (and in Jexl whose syntax is identical to JS). It should be obvious by looking at the history of JSP (which migrated from plain Java to the JSTL EL (implementd by Jexl). that a JS like approach can be preferable to Java in some cases. Opinions may vary, but to me JS is _actually_ a different language than Java and and an API that is provided in both languages should not be required to be identical in every respect (e.g. JavaFlow versus JS flow, Java DOM versus JS DOM, etc). Sylvain describes these differences as "inconsistencies", however I rather regard them as appropriate differences given the target languages (which in the case of JS will be appreciated by experienced JS programmers). The inconsistencies are not in the language itself, but IMO in the way it has been used from day one in browsers, and which has "infected" its use everywhere else afterwards. This problem is that it's rather common practice in JS to mix properties coming from different naming contexts on a single object. Consider the object in HTML: it has a submit() function which submits the form. It also has properties added for all form input. Now what happens if your form has an ? You can no more call form.submit() as the function property has been replaced by the HTMLInputElement object. I've hit this several times and spent hours finding out why my form wasn't working. 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). At any rate, I fail to understand how a massively non-backward compatible change can be made which was not even relevant to the subject voted on. As I understand it there was a vote to "unrestrict" the FOM, thereby removing the contracts from (2) above. AFAIK this could have been implemented easily without causing backward incompatibility in accessing the FOM from JS/Jexl/JXPath. 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. My $0.02, Thanks for them. It led me to expand on my reasons for this change. Sylvain -- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: JS versus Java [was Re: FOM inconsistency (was Re: [VOTE]Unrestricting the FOM)]
Chris: The name JavaScript was just a good marketing meme and the reason why Netscape choosed this name for this language called Javascript. I agree with you. Recently I found a lot of changes to java-zation of the JS Flow code. I see too much verbosity in the "new" changes. The reason to not like them. I prefer to have less code to write. If Javascript allow me it. I am happy using the real Javascript features. ;-) Best Regards, Antonio Gallardo On Sab, 26 de Febrero de 2005, 16:34, Christopher Oliver dijo: > Sorry to pick on Sylvain again, but he consistently exhibits a common > behavior of Java programmers with respect to JavaScript. Because JS > syntax is so similar to Java they seem to feel a JS API is somehow > "better" the more it resembles what it would look like if it was written > in Java. > > The "special wrapper" objects in the FOM served two purposes: > > 1) The enforced the FOM contracts which were voted on by the Cocoon > community (note that although I implemented it I did _not_ define those > contracts). > 2) They made the underlying Cocoon Java API (Request, Session, etc) > easier to access in JS (and in Jexl whose syntax is identical to JS). > > It should be obvious by looking at the history of JSP (which migrated > from plain Java to the JSTL EL (implementd by Jexl). that a JS like > approach can be preferable to Java in some cases. > > Opinions may vary, but to me JS is _actually_ a different language than > Java and and an API that is provided in both languages should not be > required to be identical in every respect (e.g. JavaFlow versus JS flow, > Java DOM versus JS DOM, etc). > > Sylvain describes these differences as "inconsistencies", however I > rather regard them as appropriate differences given the target languages > (which in the case of JS will be appreciated by experienced JS > programmers). > > At any rate, I fail to understand how a massively non-backward > compatible change can be made which was not even relevant to the subject > voted on. > > As I understand it there was a vote to "unrestrict" the FOM, thereby > removing the contracts from (2) above. AFAIK this could have been > implemented easily without causing backward incompatibility in accessing > the FOM from JS/Jexl/JXPath. > > My $0.02, > > Chris > > >>Antonio Gallardo wrote: >> >>>On Mie, 9 de Febrero de 2005, 12:06, Sylvain Wallez dijo: >>> >>> Carsten Ziegeler wrote: >Sylvain Wallez wrote: > > > >>Hi team, >> >>Several months later, it's done (the vote started on 14-06-2004). >> >>cocoon.request, cocoon.response, cocoon.context and cocoon.session >>are now unrestricted. >> >>The only difference with the real objects is that a special wrapper >>is used for request, response and context that shows their respective >>attributes are JS properties (not sure I personally like it, but >>that's how they have been since the beginning). >> >>This closes a lot of open bugs ;-) >> >> >> >Great! Why do we need this special wrapper? > > Because removing it means a backwards incompatible change! It adds small syntactic sugar by allowing you to write 'cocoon.session.blah' instead of 'cocoon.session.getAttribute("blah")' and the same on request and context. I personally didn't knew about it until today and therefore never used it... >>> >>>I thought in the form flow samples is. The construction is often used to >>>test request params. ;-) >>> >>>ie: cocoon.request.myButton >>> >>> >> >>Oh f*ck, that's even worse than I thought. It now returns the request >>*attributes* because I was fooled by the implementation of FOM_Request >>which was buggy: getIds() which lists the object's properties was >>considering *attribute* names just as FOM_Session and FOM_Context, but >>get() which actually gets a property was considering *parameter* names. >> >>What that means is that (before today's change): >>- cocoon.context.blah == cocoon.context.getAttribute("blah") >>- cocoon.session.blah == cocoon.session.getAttribute("blah") >>- cocoon.request.blah == cocoon.request.getParameter("blah") and not >>cocoon.request.getAttribute("blah"). >> >>This is clearly inconsistent. >> >>Furthermore, I really don't like this naming scope filled from different >>sources (the object itself and some other data), especially when one of >>the sources comes from the browser. >> >>And what about conflicts? Fortunately the object is searched before >>request parameters, otherwise this would be a nice security hole. >> >>So, what do we do? Do we keep this inconsistent behaviour, deprecate it, >>remove it now? >> >>WDYT? >> >>Sylvain >> >