On 27 Oct 2011, at 17:18, Igor Vaynberg wrote: > On Thu, Oct 27, 2011 at 12:29 AM, Maarten Billemont <lhun...@lyndir.com> > wrote: >> >> 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. > > this wont be a standard behavior as it would add a lot of overhead. > during listener processing you may load five LDMs with database > queries and only one of them will be effected by the form submission -
Then those four will not get loaded before rendering and there is no problem. Their models will be detached from after the last rendering, their LDMs unloaded, and with no getObject to load them before render, when this new detach-before-render is called, their internal state will still be detached. No double loading if you're not being used during event processing. Or am I wrong? If not, then perhaps it is feasible still to do this. If wicket loads all models of form components regardless, then maybe it can be made more lazy. > so why should we have to reload the other four? imho it is a well > known fact that if you do something like this: > > List<Foo> list=model.getobject(); > Foo foo=list.get(0); > removeFromDatabase(foo); > > we all understand that model.getobject() still returns an unchanged > list, so if you want a refreshed list you have to call model.detach(); I've never actually thought it necessary to invoke this method myself; I mostly considered it internal-use. But perhaps, yes, the developer should be aware of needing to do this maintenance. > > the core of your problem here is that you are using a ListView to > represent data in your database, which is something that ListView is > *not* designed to be used for. it is designed to be used with lists, > which your database tables are not. if you dont want to run into this > then use a dataview or a datatable. I'm not using a ListView (at least not directly). I'm using a DDC. And AFAIK this issue would also exist for eg. ListDataProvider. > > -igor > > >> >>> >>> 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 >> >> > > --------------------------------------------------------------------- > 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
