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
Date Mon, 28 Feb 2005 13:48:56 GMT
Daniel Fagerstrom wrote:
> Christopher Oliver wrote:
>>> Christopher Oliver wrote:
>>> <snip/>
>>>>> 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 away one of the nice things that Rhino provides us 
>>>>> which is shorter dotted notation for JavaBean properties. And 
>>>>> that's what I find confusing: once someone has understood how Java 
>>>>> objects are mapped to JS objects, he needs next to forget this 
>>>>> knowledge and learn that request, session and context have to be 
>>>>> used in a special way.
>>>> 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 any special knowledge 
>>>> to "throw away".
>>> Yes there is, because the reference objects in the case of FOM are 
>>> the *Java* objects.
>> Are they? At least to me the concepts of Request, Session, Request 
>> Parameter, Session Attribute, etc, exist independently of those Java 
>> interfaces (in fact the Servlet API presents most of the same concepts 
>> with different interfaces). Stefano and Ricardo took the time and 
>> effort to define a JS API for those concepts, which included accessing 
>> Request parameters as JS properties, and so on.  I don't see anything 
>> wrong with their API and I don't see any reason to convert it to the 
>> Java API (and there are plenty of reasons not to - for backward 
>> compatibility and ease of use, at least).
> +1
> FOM as it was until recently was based on extensive discussions in the 
> community, 
> and certainly many more threads.
> In the [RT] FOM, Stefano stated:
> The FOM is the Flow Object Model. In my vision, it's the server-side
> equivalent of the DOM.
> i.e. it is supposed to be a JS model of relevant Cocoon environments 
> following JS idioms. It is not intended to be as close as possible to 
> the Java servlet. We agreed about that back then and I still find the 
> arguments from those discussions valid.
> Furthermore our users have trusted in FOM being a stable contract and 
> based their applications on them, we should have _really_ strong reasons 
> for breaking this trust. Leszek, to take just one example estimates that 
> it will take him a couple of days to adapt his code to the new FOM, 
> Multiply this with the number of users of Flow. Are our reasons strong 
> enough to create that amount of bad will and distrust?
>                   --- o0o ---
> Chris implemented Stefano's and Richardo's (and the rest of the 
> communities) design 
> The so called "inconsistencys" are part of the initial design as can be 
> seen there. The mixing of attribute and map name spaces in FOM is, as 
> Chris said a usablity tradeof and a common JS idiom. 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}
> Now after the "improvement" you must do:
> ${cocoon.session.getAttribute('user').id}
> #{getAttribute($cocoon/session, 'user')/id}
> instead.
>                   --- o0o ---
> IMO we should go back to the earlier behaviour of FOM, that our users 
> depend on and fix whats broken there instead of just throwing everything 
> away.
> If we can find way to simplify the FOM code, thats excelent, but not at 
> the cost of usabillity and compability.
> Furthermore we should IMO factor out FOM from flowscript to general 
> environment handling, as script style (JS) environment embeding is 
> needed for use with expression languages in templates and possibly also 
> in the sitemap.
>> After all, if you really want to use the Java API, you can now use 
>> Java Flow right?
> Exactly, its fine that Cocoon is implemented in Java, but we shouldn't 
> design flowscript, template, sitemap and so on under the assumption that 
> Java APIs are natural and familiar for all our users.

+1 to all your arguments!

Reinhard Pötz           Independant Consultant, Trainer & (IT)-Coach 

{Software Engineering, Open Source, Web Applications, Apache Cocoon}


View raw message