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. And these are the ones we use everywhere in Java code. I may have not said the same thing for objects that have no commonly-used Java counterpart (e.g. a WebContinuation), but this isn't the case here.
Although it really doesn't matter much to me since I don't use Cocoon, it appears to me to be in the interest of the Cocoon community to reimplement the "unrestricting" of the FOM without using direct Rhino wrappers of o.a.c.environment.Request, etc Java interfaces.
Ok, thanks for you opinion.
Sylvain
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
