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




Reply via email to