JS versus Java [was Re: FOM inconsistency (was Re: [VOTE] Unrestricting the FOM)]

2005-02-26 Thread Christopher Oliver
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 "sp

Re: JS versus Java [was Re: FOM inconsistency (was Re: [VOTE]Unrestricting the FOM)]

2005-02-26 Thread Antonio Gallardo
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 lik

Re: JS versus Java [was Re: FOM inconsistency (was Re: [VOTE] Unrestricting the FOM)]

2005-02-27 Thread Sylvain Wallez
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

Re: JS versus Java [was Re: FOM inconsistency (was Re: [VOTE] Unrestricting the FOM)]

2005-02-27 Thread Reinhard Poetz
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

Re: JS versus Java [was Re: FOM inconsistency (was Re: [VOTE] Unrestricting the FOM)]

2005-02-27 Thread Carsten Ziegeler
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 i

Re: JS versus Java [was Re: FOM inconsistency (was Re: [VOTE] Unrestricting the FOM)]

2005-02-27 Thread Sylvain Wallez
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 ca

Re: JS versus Java [was Re: FOM inconsistency (was Re: [VOTE] Unrestricting the FOM)]

2005-02-27 Thread Don Brown
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-f

Re: JS versus Java [was Re: FOM inconsistency (was Re: [VOTE] Unrestricting the FOM)]

2005-02-27 Thread Don Brown
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" prop

Re: JS versus Java [was Re: FOM inconsistency (was Re: [VOTE] Unrestricting the FOM)]

2005-02-27 Thread Sylvain Wallez
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

Re: JS versus Java [was Re: FOM inconsistency (was Re: [VOTE] Unrestricting the FOM)]

2005-02-27 Thread Don Brown
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 >