The point of having a detachable model is to avoid storing the domain
object into the wicket session. The constructor you mention is wrongly
quoted, the code is in fact:
public DetachableContactModel(Contact c)
{
this(c.getId());
}
There isn't even a contact field in the class. If there were one,
Contact should be serializable.
So you store just the id into the session and load the actual Contact
from the db upon each request. Working this way you avoid some common
problems when navigating lazy associations from your entity, and in
general you don't need to reattach your detached entity before
carrying on any operation that involves persistent state.
Regards,
Carlos
On 9/6/07, Cristi Manole <[EMAIL PROTECTED]> wrote:
> Hello,
>
> In the repeteater samples, the one with ajax capability you have
> DetachableContactModel.
>
> My question is why
>
> protected Object load()
> {
> // loads contact from the database
> return getContactsDB().get(id);
> }
>
> does not just return the Contact object?
>
> It is already determined by the constructor.
> public DetachableContactModel(Contact c)
> {
> this(c.getId());
> contact = c;
> }
> [this is the one called by SortableDataProvider]
>
> Why the extra roundtrip to the database?
>
> Sorry if this is a silly question.
>
> Thks in advance.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
