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
