cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <reinhard_po...@yahoo.de>
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 http://marc.theaimsgroup.com/?t=105401789500001&r=1&w=2, 
> http://marc.theaimsgroup.com/?t=105572173100003&r=1&w=2,
> http://marc.theaimsgroup.com/?t=105588670600005&r=1&w=2,
> http://marc.theaimsgroup.com/?t=105794471900001&r=1&w=2
> 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, 
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=110942199227672&w=2. 
> 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 
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105401786813250&w=2. 
> 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}
> #{$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}

                                        web(log): http://www.poetz.cc
--------------------------------------------------------------------


Mime
View raw message