Vadim Gritsenko wrote:
Christopher Oliver wrote:
That's not the case. All are equally crippled ;) For example, when using Xsp, the idea is that the only logic sheet you will ever use is the jpath logic sheet. This does not give you direct access to session, request, or context but only to the bean object. Likewise with XMLForm, you only have access to the bean itself.
HUH? /me extremely puzzled
Sorry, I'm not doing a better job explaining...
No, I understood what you said, I'm puzzled by the decision taken.
Since you responded to it I guess you did read this:
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=103128978404439&w=2
I'll bookmark it :)
I'm not saying anything different. To quote Ovidiu:
"The above explains how MVC could be really achieved in Cocoon with the
control flow layer. Note that there is no direct communication between
Model and View, everything is directed by the Controller by passing to
View a context object constructed from Model data. In a perfect world,
Usually, there is a problem with something "perfect" - it ends up dead ;-) (i.e.: ideal is not achievable)
I've not thought a lot about "flow-bean-only-controlled-data-generation", but from the short glance I see that some of the existing Cocoon parts won't be easily integrated with this approach. Thus, it's logical to assume that one should still have access to request/session as one had it before.
You may discourage usage of these objects for the sake of perfectness of the MVC in the documentation but I don't think you should insist on disabling access to them (like in FlowVelocityGenerator).
Fair?
Vadim
XSP should have only one logicsheet, the JXPath logicsheet. There should be no other things in an XSP page that put logic in the page (read View), instead of the Model. If you don't like XSP, and prefer to use JSP or Velocity, the JXPath logicsheet equivalents should be implemented."
Regards,
Chris
