cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <>
Subject Re: JS versus Java [was Re: FOM inconsistency (was Re: [VOTE] Unrestricting the FOM)]
Date Sun, 27 Feb 2005 09:38:58 GMT
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}


View raw message