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
form 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 input name=submit? 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)]
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)]
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? 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 :) 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, SN 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)]
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 }
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:
snip /
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
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 }
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:
snip /
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
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 }
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:
snip /
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)]
On Sun, 27 Feb 2005 23:15:00 +0100, Sylvain Wallez [EMAIL PROTECTED] wrote:
snip /
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 }
JS versus Java [was Re: FOM inconsistency (was Re: [VOTE] Unrestricting the FOM)]
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
Re: FOM inconsistency (was Re: [VOTE] Unrestricting the FOM)
Antonio Gallardo wrote:
snip/
I found time to update the SVN version and an application that works fine
using the lastest SVN version seems to be broken.
I added 2 lines in javascript flow code for test:
cocoon.log.error(name= + cocoon.request.name);
cocoon.log.error(name= + cocoon.request.getParameter(name));
And the result is:
name=undefined
name=antonio
Then the original cocoon.request.name is not working anymore. It was
simply a very big poof! ;-)
Seriously, can you review the change just to deprecate it. :-)
Ooops, I'll fix that ASAP.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: FOM inconsistency (was Re: [VOTE] Unrestricting the FOM)
Sylvain Wallez wrote: Carsten Ziegeler wrote: I personally would remove this syntactic sugar completly; it's imho not intuitiv what it means and the inconsistent implementation adds to it. In addition it would make our unified object model implementation (for flow, jxtg etc.) much easier as we don't have to simulate this in Java. Unfortunately, I fear that this is common use, so let's deprecate it with 2.1.x and remove for 2.2 completly agree :-) We have the same functionality in flow, e.g. you can get the value of a widget using the model with model.WIDGETID. I think we should deprecate (and remove) this as well. Can you start a formal vote about it? Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: FOM inconsistency (was Re: [VOTE] Unrestricting the FOM)
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
Carsten Ziegeler wrote:
I personally would remove this syntactic sugar completly; it's imho
not intuitiv what it means and the inconsistent implementation adds
to it.
In addition it would make our unified object model implementation
(for flow, jxtg etc.) much easier as we don't have to simulate this
in Java.
Unfortunately, I fear that this is common use, so let's deprecate it
with 2.1.x and remove for 2.2 completly
agree :-)
We have the same functionality in flow, e.g. you can get the value of
a widget using the model with model.WIDGETID. I think we should
deprecate (and remove) this as well.
Yep. We have form.model that gives access to a JS-specific API of
widgets which does have its set of inconsistencies.
Can you start a formal vote about it?
Yup.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: FOM inconsistency (was Re: [VOTE] Unrestricting the FOM)
On Jue, 10 de Febrero de 2005, 7:51, Sylvain Wallez dijo:
oceatoon wrote:
Hmm... the problems is that cocoon.request.blah was released and
maybe
is used is used (by us and other people?) in a lot of places and maybe
other peopl! :-(
Sorry for peecking into this post but till today I thought
cocoon.request.blah was a normal call, and seemed quite natural ;) in a
users perspective. I do use it massively.
So the correct way of doing this would be
cocoon.request.getParameter(blah) then ?
Exactly. Don't know yet how/if parameters will be available as
properties in the future, but for sure cocoon.request.getParameter()
will always work.
before it blows off with 2.2
Poof :-)
What a big poof! It reached 2.1.7-dev!!! ;-)
I found time to update the SVN version and an application that works fine
using the lastest SVN version seems to be broken.
I added 2 lines in javascript flow code for test:
cocoon.log.error(name= + cocoon.request.name);
cocoon.log.error(name= + cocoon.request.getParameter(name));
And the result is:
name=undefined
name=antonio
Then the original cocoon.request.name is not working anymore. It was
simply a very big poof! ;-)
Seriously, can you review the change just to deprecate it. :-)
Best Regards,
Antonio Gallardo
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: FOM inconsistency (was Re: [VOTE] Unrestricting the FOM)
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
Now with all this deprecated stuff floating around, we should have a
centralized deprecation Logger so that users can easily be informed
of the deprecated features they use (in the case of Javascript,
there's no compiler warning like in Java).
That would make a new log file (e.g. deprecated.log), but IMO that
one deserves to exist.
Yes, and we should really try to add *all* deprecated log messages
there.
And punish those that fail to use it once it's in place ;-)
Where can we put that deprecation logger? What comes to mind is
either the Avalon Context, or a component, i.e. lookup(Logger.ROLE +
deprecated).
WDYT?
I think this should be as simple as possible. What about a static
accessor, e.g. on the Core object? You might want to use this logger
where you don't want to either implement Serviceable nor
Contextualizable, so imho it should be easier.
Yeah, I thought about a static accessor also, but I'm fearing some
problems with classloading. Well, if any such problem arises, we'll be
able to solve it withing the accessor's code.
So let's go for Cocoon.getDeprecationLogger().
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: FOM inconsistency (was Re: [VOTE] Unrestricting the FOM)
Sylvain Wallez wrote: Thinking further, I don't think we should attach this to the Cocoon object as we may want to use this in classes also used outside the Cocoon machinery. Outside the Cocoon machinery? What do you mean by this? So what about a dedicated o.a.c.util.Deprecation class? Sylvain -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: FOM inconsistency (was Re: [VOTE] Unrestricting the FOM)
Hmm... the problems is that cocoon.request.blah was released and maybe is used is used (by us and other people?) in a lot of places and maybe other peopl! :-( Sorry for peecking into this post but till today I thought cocoon.request.blah was a normal call, and seemed quite natural ;) in a users perspective. I do use it massively. So the correct way of doing this would be cocoon.request.getParameter(blah) then ? before it blows off with 2.2 Thanks Tibor
Re: FOM inconsistency (was Re: [VOTE] Unrestricting the FOM)
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
Thinking further, I don't think we should attach this to the Cocoon
object as we may want to use this in classes also used outside the
Cocoon machinery.
Outside the Cocoon machinery? What do you mean by this?
I mean not tied to a class that provides other features than deprecation
logging. And the Cocoon class provides so much more ;-)
Hence the specific Deprecation class below, which will of course be in
the org.apache.cocoon package hierarchy.
So what about a dedicated o.a.c.util.Deprecation class?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: FOM inconsistency (was Re: [VOTE] Unrestricting the FOM)
oceatoon wrote:
Hmm... the problems is that cocoon.request.blah was released and maybe
is used is used (by us and other people?) in a lot of places and maybe
other peopl! :-(
Sorry for peecking into this post but till today I thought
cocoon.request.blah was a normal call, and seemed quite natural ;) in a
users perspective. I do use it massively.
So the correct way of doing this would be
cocoon.request.getParameter(blah) then ?
Exactly. Don't know yet how/if parameters will be available as
properties in the future, but for sure cocoon.request.getParameter()
will always work.
before it blows off with 2.2
Poof :-)
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: FOM inconsistency (was Re: [VOTE] Unrestricting the FOM)
Sylvain Wallez wrote: I mean not tied to a class that provides other features than deprecation logging. And the Cocoon class provides so much more ;-) Hence the specific Deprecation class below, which will of course be in the org.apache.cocoon package hierarchy. Ok: +1 - I would choose a different name than Deprecation (DeprecationUtil or DeprecationLogger), but that's not that important. Choose whatever you think is best. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
FOM inconsistency (was Re: [VOTE] Unrestricting the FOM)
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
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: FOM inconsistency (was Re: [VOTE] Unrestricting the FOM)
Sylvain Wallez wrote: This is clearly inconsistent. Yepp 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? I personally would remove this syntactic sugar completly; it's imho not intuitiv what it means and the inconsistent implementation adds to it. In addition it would make our unified object model implementation (for flow, jxtg etc.) much easier as we don't have to simulate this in Java. Unfortunately, I fear that this is common use, so let's deprecate it with 2.1.x and remove for 2.2 completly Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: FOM inconsistency (was Re: [VOTE] Unrestricting the FOM)
On Mie, 9 de Febrero de 2005, 13:58, Sylvain Wallez dijo: 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. It was carefully designed. ;-) So, what do we do? Do we keep this inconsistent behaviour, deprecate it, remove it now? Hmm... the problems is that cocoon.request.blah was released and maybe is used is used (by us and other people?) in a lot of places and maybe other peopl! :-( I think the best is to keep the 2.1.x as is and perhas deprecate it in the next (2.1.7) release and remove it in 2.2. ... [Antonio while typing, pausing to answer customer's questions by phone saw that Sylvain already fixed the problem. Antonio is very happy and wants to test the last change.] ... Anyway, you are faster than me! I already saw the last patch. I will check if it is working now as expected. Mr. Incredible, thanks for you time! ;-) Best Regards, Antonio Gallardo
Re: FOM inconsistency (was Re: [VOTE] Unrestricting the FOM)
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
This is clearly inconsistent.
Yepp
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?
I personally would remove this syntactic sugar completly; it's imho
not intuitiv what it means and the inconsistent implementation adds to
it.
In addition it would make our unified object model implementation (for
flow, jxtg etc.) much easier as we don't have to simulate this in Java.
Unfortunately, I fear that this is common use, so let's deprecate it
with 2.1.x and remove for 2.2 completly
agree :-)
Now with all this deprecated stuff floating around, we should have a
centralized deprecation Logger so that users can easily be informed of
the deprecated features they use (in the case of Javascript, there's no
compiler warning like in Java).
That would make a new log file (e.g. deprecated.log), but IMO that one
deserves to exist.
Where can we put that deprecation logger? What comes to mind is either
the Avalon Context, or a component, i.e. lookup(Logger.ROLE + deprecated).
WDYT?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: FOM inconsistency (was Re: [VOTE] Unrestricting the FOM)
Le 9 févr. 05, à 21:27, Carsten Ziegeler a écrit : ...Unfortunately, I fear that this is common use, so let's deprecate it with 2.1.x and remove for 2.2 completly +1 -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: FOM inconsistency (was Re: [VOTE] Unrestricting the FOM)
Antonio Gallardo wrote:
On Mie, 9 de Febrero de 2005, 13:58, Sylvain Wallez dijo:
snip/
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.
It was carefully designed. ;-)
Flowscript is a nice invention, but custom JS wrappings have been used
in weird ways...
So, what do we do? Do we keep this inconsistent behaviour, deprecate it,
remove it now?
Hmm... the problems is that cocoon.request.blah was released and maybe
is used is used (by us and other people?) in a lot of places and maybe
other peopl! :-(
I think the best is to keep the 2.1.x as is and perhas deprecate it in
the next (2.1.7) release and remove it in 2.2.
Yep. Sounds reasonable.
[Antonio while typing, pausing to answer customer's questions by phone saw
that Sylvain already fixed the problem. Antonio is very happy and wants to
test the last change.]
...
Anyway, you are faster than me! I already saw the last patch. I will check
if it is working now as expected. Mr. Incredible, thanks for you time! ;-)
Well, I don't have that much time for Cocoon development lately
(although I'm using it for very fancy stuff), but one thing I really
hate is leaving bugs unfixed in what I wrote once I've identified them ;-)
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: FOM inconsistency (was Re: [VOTE] Unrestricting the FOM)
Sylvain Wallez wrote: Carsten Ziegeler wrote: Sylvain Wallez wrote: This is clearly inconsistent. Yepp 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? I personally would remove this syntactic sugar completly; it's imho not intuitiv what it means and the inconsistent implementation adds to it. In addition it would make our unified object model implementation (for flow, jxtg etc.) much easier as we don't have to simulate this in Java. Unfortunately, I fear that this is common use, so let's deprecate it with 2.1.x and remove for 2.2 completly agree :-) Now with all this deprecated stuff floating around, we should have a centralized deprecation Logger so that users can easily be informed of the deprecated features they use (in the case of Javascript, there's no compiler warning like in Java). That would make a new log file (e.g. deprecated.log), but IMO that one deserves to exist. Yes, and we should really try to add *all* deprecated log messages there. Where can we put that deprecation logger? What comes to mind is either the Avalon Context, or a component, i.e. lookup(Logger.ROLE + deprecated). WDYT? I think this should be as simple as possible. What about a static accessor, e.g. on the Core object? You might want to use this logger where you don't want to either implement Serviceable nor Contextualizable, so imho it should be easier. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: FOM inconsistency (was Re: [VOTE] Unrestricting the FOM)
Carsten Ziegeler wrote: I think this should be as simple as possible. What about a static accessor, e.g. on the Core object? I meant the Cocoon object here (we are talking about 2.1.x). You might want to use this logger where you don't want to either implement Serviceable nor Contextualizable, so imho it should be easier. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
