Vadim Gritsenko wrote:
Daniel Fagerstrom wrote:
oceatoon wrote:
Why step away from the global session though,
and create a new FOM_session structure? your answer was "design decision
but I don't understand, why ?
Neither do I, it wasn't my decison but Chris Olivers. One reason might be that flow uses a special embedinging of the request object etc to make them easy to use in Java script,
FOM's FOM_Cocoon / FOM_Request / etc objects are results of conscious community effort to define FOM (Flow Object Model), all its objects, and all methods on those objects. You will notice that not all methods of underlying Cocoon Request / Response / etc API were exposed, and this was done for a reason.
Thanks for reminding.
I searched the archives and found lots of discussions about it but not any summary of the actual decision.IIRC, see archives for thread "less is more".
The goal is to have the FOM view from JXTG available in other places in Cocoon, e.g. in an ExpressionModule. To achive this I used Carsten's TemplateObjectModelHelper, that makes the same object available as the FOM in flowscript. But it does that through a reflection based "dynamic map" instead of by implementing the interface in a JS friendly way as in the flowscript implementation.This makes, if I understand you right more methods available than it should. Is that important? What do yo think we should do about it?
/Daniel
