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
