I have to admit I haven't read thru all of this thread, so my answer
might be to something else... But here we go:
I think we actually do something very similar to this in our system,
we automatically detach any instances of jpa-enitities (replacing them
with a surrogate with only the class and id) and then get them again
from the db-cache if the page is reconstructed again. So far it works
like a charm and the programming model is very convinient. Just dump
whatever entity you like as member of a component and it is
automatically detached and then loaded back when needed.
I implemented this by hooking in to serialization, just checking each
object in ObjectOutputStream.replaceObject and
ObjectInputStream.resolveObject. Also had to use my own PageMapEntries
to get a suitable hook. Might work as an idea for your implementation
perhaps?
// Daniel
jalbum.net
On 2008-06-04, at 19:03, Eelco Hillenius wrote:
> On Wed, Jun 4, 2008 at 9:43 AM, Igor Vaynberg
> <
igor.vaynberg@...> wrote:
>> you still have ondetach()...but for convinience we can automatically
>> detach any imodel fields, i actually wanted to do this for a while...
>
> I tried to write this two days ago, but wasn't able to pull it off...
> I wrote an instantiation listener that introspected on the fields of
> components and replaced IModel members with a proxy. These proxies
> would register themselves with the request cycle for cleaning up
> whenever the getObject was called, and the request cycle then would go
> through the list of registered models and detach them at the end of
> the request. The problem I ran into however is that these members can
> be final, assigned at a later stage (typically are actually) and such.
>
> But if there is some way to automatically detach model members, we
> could get rid of the model member in component and instead just let
> components have models by default where it actually always makes
> sense, such as form components.
>
> Anyway, that's something for 1.5. If it is fixable, I think that would
> be the way out of the generics controversy :-)
>
> Eelco
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
users-unsubscribe@...
> For additional commands, e-mail:
users-help@...
>
---------------------------------------------------------------------
To unsubscribe, e-mail:
users-unsubscribe@...
For additional commands, e-mail:
users-help@...
