On Fri, Oct 28, 2011 at 8:10 AM, Bertrand Guay-Paquet <ber...@step.polymtl.ca> wrote: > Hi, >>> >>> 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. > > Some LDMs could be loaded which we know won't be affected by the form > processing. I think that was Igor's point. However, is there a way to datach > _all_ models as is done after page rendering? This could be called > explicitly if we want such behavior after form processing to detach > everything between the listener and the renderer.
getPage().detach(); > I still see 2 issues with this however in favor of forcing detachment of > models between the listener and the renderer: > Issue 1: With an ajax form submit, some components could be triggering the > load of LDMs in their onEvent for the "default ajax event". They would have > a tough time knowing that they should detach their models since this request > is a form submit that invalidates their data. This can happen with other > events as well. > > Issue 2: With stateless ajax, IIRC the flow is the following: > s1-create new page (components can load some LDMs in constructors, > onInitialize, etc.) > s2-invoke listener > s3-render ajax request target > During s1 some loaded LDMs could very well be invalidated by what is done in > s2. The listener has no way of knowing about LDMs loaded by other components > in the new page instance so it can't detach them. > > In my opinion, these are 2 problems which are very hard to solve without > systematic detaching of models between the listener and the renderer. and here is a simple counter example. your form has five dropdowns, all of which are populated by various queries and all of which are not effected by the submit. now on every single submit you have to run 10 queries instead of 5, for no good reason. the point being that right now we leave the room for manual eviction - allowing both usecases to be implemented (some models that are detached and others that are not). by force-detaching everything we remove the possibility to implement the usecase where certain models do keep their state. this is, imho, unacceptable. neither approach is perfect, but at least the current one leaves more doors open. further, in the project's lifetime this has only come up a few times, so obviously it is somewhat well understood and not difficult to deal with. one minor improvement i can see is to allow the default model to implement ieventsink and participate in event processing by default. this should make it simpler to automatically detach certain models no matter where they are on the page. -igor > > Regards, > Bertrand > > --------------------------------------------------------------------- > 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
