On Sunday, July 13, 2003, at 10:30 AM, Reinhard Pötz wrote:
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?
I reckon we do
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.
Interesting ..... I am not entirely sure how right now, but will look into this.
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?
OK, yes in this simple case you are right.
I am too tied up in my head with my current project where I have lots of "one-to-many" and "many-to-many" relationships between composite beans, whereby loading one Bean would conceptually load >10k rows out of my DB.
Under these circumstances I take advantage of lazy-initialisation and let the view layer decide that it wants to show (eg.) siblings (bean.parent.children) for navigation purposes, or just a few local properties (bean.name, bean.description etc.) for editing.
Additionally, in the case of editing, I tend to copy the editable properties to a temporary JS Properties list to pass to the view layer as I do not wish to be bothered with rolling back any changes if the user cancels halfway through, though this might not be one of my best design decisions ;)
regards Jeremy
