Hi,
>> Or use a separate LDM for each of your list items
>I'm not sure I understand what you mean here. Could you illustrate?
your LDM seems to return a list of items and you're iterating over them with
a ListView. Note that ListView uses a ListItemModel for each item:
protected IModel<T> getListItemModel(final IModel<? extends List<T>>
listViewModel,
final int index)
{
return new ListItemModel<T>(this, index);
}
A ListItemModel depends on the ListView's model. If you create a smarter
model (e.g. loading an entity via its primary key), it will work
independently:
@Overwrite
protected IModel<T> getListItemModel(final IModel<? extends List<T>>
listViewModel,
final int index)
{
return new EntityModel(this,
listViewModel.getObject().get(index));
}
This is done with IDataProvider/DataTable usually.
>It seems to me that Wicket should detach its models again after events have
triggered, in addition to after rendering has >completed. That would reset
the state of all models to what the developer expects it to be before
rendering begins.
You can hook your own listener into Wicket (I*Listener) and detach the
models yourself.
HTH
Sven
-----Ursprüngliche Nachricht-----
Von: Maarten Billemont [mailto:lhun...@lyndir.com]
Gesendet: Mittwoch, 26. Oktober 2011 11:50
An: users@wicket.apache.org
Betreff: Re: LDMs load too early - hold outdated application data.
On 26 Oct 2011, at 10:52, Sven Meier wrote:
> This is a common problem when working with LDM. You can detach the LDM by
> yourself after the event.
I could. But it would be a work-around and it wouldn't solve the underlying
issue. As a result, this bug will keep haunting us.
> Or use a separate LDM for each of your list items:
> This way the LDM of the list is loaded for rendering *after* the event
only.
> Additionally the event won't crash when the list of users has changed
while
> the page is displayed.
I'm not sure I understand what you mean here. Could you illustrate?
It seems to me that Wicket should detach its models again after events have
triggered, in addition to after rendering has completed. That would reset
the state of all models to what the developer expects it to be before
rendering begins.
>
> HTH
> Sven
>
> -----Ursprüngliche Nachricht-----
> Von: Maarten Billemont [mailto:lhun...@lyndir.com]
> Gesendet: Mittwoch, 26. Oktober 2011 10:15
> An: users@wicket.apache.org
> Betreff: LDMs load too early - hold outdated application data.
>
> I just had a bug in my application where my LDM lists all users to fill a
> form field, but that same form also has a button to delete the selected
user
> from the database.
>
> The problem is that the button's onSubmit triggers AFTER the LDM is
> populated, because it apparently needs the LDM's information to figure out
> what user was selected in the form (so, to figure out what user to
delete).
>
> Only, once the button's onSubmit has triggered, the user is deleted from
> persistence, and to render an up-to-date page, the LDM's model should NO
> LONGER include that user. I had initially assumed this would work fine
> because the LDM reloads its model for each page refresh, but in this
> scenario the LDM is only loaded before the persistence layer is up-to-date
> with the information that needs to be rendered.
>
> Which leads me to wonder the following:
> Shouldn't an LDM load its state from up-to-date data? Shouldn't its
load()
> be invoked AFTER all events have been handled? Shouldn't the response
page
> be rendered AFTER all logic has been processed? And shouldn't the LDM use
> FRESH data for that rendering, rather than using the state from BEFORE the
> logic was processed? Isn't this a bug in the way wicket handles model
> object loading? It certainly doesn't stroke with what a developer might
> intuitively expect from an LDM - so there's some kind of mismatch going
on.
> And personally, I'd really like to be able to TRUST that my LDMs are
ALWAYS
> populated from CURRENT data when the response rendering that uses it
> happens.
> ---------------------------------------------------------------------
> 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
>
---------------------------------------------------------------------
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
