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 >> >