On 26 Oct 2011, at 12:14, Sven Meier wrote: > 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:
Fair. Though my actual use case is an LDM that populates a dropdown. There is only one button in the form to delete the dropdown's selected object, whose onSubmit uses the dropdown's model to determine what object to delete. >> It seems to me that Wicket should detach its models again after events have >> triggered, in addition to after rendering has >completed. That would >> resetthe 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. If we can think of no issues with this approach, I'd much rather vote to make it standard behavior in Wicket, so that developers can trust their models behave as they'd expect. > > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
