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
Christopher Oliver wrote:
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
Christopher Oliver wrote:
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
This is a tradeoff: by "combining" properties you get easer access to
commonly used properties, but however at the cost of overloading the
identifiers at times. Note that it's always possible to provide an
"escape" mechanism to disambiguate such cases, even if DOM didn't do
that in this case.
Christopher Oliver wrote:
Mmmh... you're right, there _wasn't_ such a property before my
changes. This explains the lengthy wrapping code that was in
FOM_Request that exposed only functions and no properties except the
request parameters (or attributes for session and context).
Now this throws
Christopher Oliver wrote:
Mmmh... you're right, there _wasn't_ such a property before my
changes. This explains the lengthy wrapping code that was in
FOM_Request that exposed only functions and no properties except the
request parameters (or attributes for session and context).
Now this throw
Christopher Oliver wrote:
Christopher Oliver wrote:
Mmmh... you're right, there _wasn't_ such a property before my
changes. This explains the lengthy wrapping code that was in
FOM_Request that exposed only functions and no properties except
the request parameters (or attributes for session and
Daniel Fagerstrom wrote:
Christopher Oliver wrote:
Christopher Oliver wrote:
Mmmh... you're right, there _wasn't_ such a property before my
changes. This explains the lengthy wrapping code that was in
FOM_Request that exposed only functions and no properties except
the request parameters (or a
Daniel Fagerstrom wrote:
Christopher Oliver wrote:
JS objects can and do exist without directly "wrapping" Java objects.
If you had accepted the original design which made FOM_Request,
FOM_Session, etc, first-class JS objects (i.e. _not_ "mapped"
versions of the Java objects) then there isn't a
Sylvain Wallez wrote:
Daniel Fagerstrom wrote:
Furthermore Chris made it possible to use parts of FOM in a
systematic way from both Jexl and JXPath in JXTG. So that you could
do things like:
${cocoon.session.user.id}
#{$cocoon/session/user/id}
Now after the "improvement" you must do:
${cocoon.s
Daniel Fagerstrom wrote:
Sylvain Wallez wrote:
Daniel Fagerstrom wrote:
Furthermore Chris made it possible to use parts of FOM in a
systematic way from both Jexl and JXPath in JXTG. So that you could
do things like:
${cocoon.session.user.id}
#{$cocoon/session/user/id}
Now after the "improvemen
Sylvain Wallez wrote:
I admit however there is a possibly incompatible change: as JavaBean
properties of the underlying objects are now exposed as JS properties,
those may take precedence over the request parameters having the same
name. I'm of course ready to fix this, so that there is absolute
Daniel Fagerstrom wrote:
I based my comment on:
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=110942199227672&w=2
Ah yes. I was referring to 2.1 and double checked it before sending, and
forgot is had already been removed in 2.2. You therefore had some valid
points. Sorry for the rant, but th
Sylvain Wallez wrote:
Daniel Fagerstrom wrote:
I based my comment on:
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=110942199227672&w=2
Ah yes. I was referring to 2.1 and double checked it before sending, and
forgot is had already been removed in 2.2. You therefore had some valid
points. Sorr
Reinhard Poetz wrote:
Sylvain Wallez wrote:
Daniel Fagerstrom wrote:
I based my comment on:
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=110942199227672&w=2
Ah yes. I was referring to 2.1 and double checked it before sending,
and forgot is had already been removed in 2.2. You therefore had som
You know what? I'm fed up with this discussion, and will start writing a
new implementation of the JS flowscript engine. People will have the
choice. And Chris will stop popping up as soon as someone touches his code.
Sylvain
Very nice display of community leadership...
I have no problem with a
Christopher Oliver wrote:
You know what? I'm fed up with this discussion, and will start writing
a new implementation of the JS flowscript engine. People will have the
choice. And Chris will stop popping up as soon as someone touches his
code.
Sylvain
Very nice display of community leadership.
Stefano Mazzocchi wrote:
Christopher Oliver wrote:
You know what? I'm fed up with this discussion, and will start
writing a new implementation of the JS flowscript engine. People
will have the choice. And Chris will stop popping up as soon as
someone touches his code.
Sylvain
Very nice display
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
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
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
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
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
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
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
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
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
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
>
28 matches
Mail list logo
