From: Jeremy Quinn [mailto:[EMAIL PROTECTED]
> By passing a Bean persisted by Hibernate from the flow layer to the > view layer, you are implementing SoC by allowing the view layer to > decide what is relevant for that view. This aspect not being > the Flow's > concern. Only to make it transparent (for me): The flow layer passes e.g. a user bean with the id 4711 to the view layer. The view layer only "knows" that it can expect a user bean and has tho show e.g. the name and the adress and so it doesn't care where the bean comes from (database, webservice, ...). Do we agree on this? > > However, once you have triggered the view layer with > SendPageAndWait(), > control does not return to the flow layer until the Response has been > sent and the next Request received, thus loosing you the > opportunity to > close the Hibernate Session from the Flow layer before the > Response is > sent. Chris' experimental implementation of cocoon.getComponent() should solve this problem. > SendPage() might not suffer this problem, but due to the nature of a > SAX event pipeline, I would not bet on it. > > With 'lazy initialisation' SQL Queries are only made when getter > methods of the Bean are executed. If you have passed the Bean to the > view layer, XPath expressions in JXPathTemplate (etc.) will result in > those getter methods being accessed. If your flowscript has already > released it's Hibernate Component, you are in trouble. > > You could clone the Bean to pass it to the view layer, but it is kind > of self-defeating IMHO. Why do you think it is self-defeating? IIUC the point of lazy initialization is calling the persistence layer at the time when it is really needed (when I generate some output). If I pass the bean with sendPageAndWait("myPage", {bean:bean}) I *already know* that I need this bean - otherwise I wouldn't pass it, wouldn't I? Cheers, Reinhard