Re: Complications with loadable detachable models

2009-11-20 Thread Igor Vaynberg
initialize them lazily just like the model would

private transient Foo foo;

private Foo getFoo() { if (foo==null) { foo=...; } return foo; }

-igor

On Fri, Nov 20, 2009 at 10:54 AM,   wrote:
> Hi
>
> It appears that I am fighting against the framework that limits my
> choices when I start using LDMs (LoadableDetachableModel).
>
> Many examples in the framework documentation don't use LDMs. For
> simplicity, they assume that the domain object e.g. person is
> available to a model in an instance variable.
>
> But LDM use is Wicket best practice. So if I switch to LDMs, then I
> remove instance variables containing domain objects to avoid their
> leakage into the session.
>
> As a consequence of that, I must use wrapped PropertyModels that use
> reflection and that are not refactor safe.
>
> In addition, in onSubmit() methods, I have to manually extract the
> domain object from the model.
>
> If I use simple custom models per form field, overriding
> org.apache.wicket.model.Model with inner classes, then I have to
> manually extract the domain object from the LDM for each
> setObject(...) and getObject() method.
>
> To avoid these obstacles I would keep for convenience a transient
> instance of the domain object. In onDetach(), I would set it to null
> to avoid leakage into the session.
>
> But how do I initialize it? I can do it in a Panel's constructor, but
> in a stateful page, the constructor of a Panel is not called when it
> is taken out of the session.
>
> I found Page.onPageAttached() interesting for that, but I cannot use
> it with a Panel sub class that is not hard-wired into the Page.
>
> How can I use LDMs without this conflict? In the described scenario,
> Wicket is really difficult to use, and that is because one has to be
> so careful about domain objects leaking into the session.
>
> Many thanks
>
> Bernard
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Complications with loadable detachable models

2009-11-20 Thread bht
Hi

It appears that I am fighting against the framework that limits my
choices when I start using LDMs (LoadableDetachableModel).

Many examples in the framework documentation don't use LDMs. For
simplicity, they assume that the domain object e.g. person is
available to a model in an instance variable.

But LDM use is Wicket best practice. So if I switch to LDMs, then I
remove instance variables containing domain objects to avoid their
leakage into the session.

As a consequence of that, I must use wrapped PropertyModels that use
reflection and that are not refactor safe.

In addition, in onSubmit() methods, I have to manually extract the
domain object from the model.

If I use simple custom models per form field, overriding
org.apache.wicket.model.Model with inner classes, then I have to
manually extract the domain object from the LDM for each
setObject(...) and getObject() method.

To avoid these obstacles I would keep for convenience a transient
instance of the domain object. In onDetach(), I would set it to null
to avoid leakage into the session.

But how do I initialize it? I can do it in a Panel's constructor, but
in a stateful page, the constructor of a Panel is not called when it
is taken out of the session.

I found Page.onPageAttached() interesting for that, but I cannot use
it with a Panel sub class that is not hard-wired into the Page.

How can I use LDMs without this conflict? In the described scenario,
Wicket is really difficult to use, and that is because one has to be
so careful about domain objects leaking into the session.

Many thanks

Bernard


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org