cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Quinn <jer...@media.demon.co.uk>
Subject Re: Flow Database stuff ( The new FOM? )
Date Mon, 14 Jul 2003 10:02:19 GMT

On Sunday, July 13, 2003, at 10:30 AM, Reinhard Pötz wrote:

>
> From: Jeremy Quinn [mailto:jeremy@media.demon.co.uk]
>
>> 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


Mime
View raw message