On 28 Oct 2011, at 17:52, Igor Vaynberg wrote:

> 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.

Would you mind explaining why every submit needs to run 10 queries and what 
causes those 10 queries to get executed?

If the form has 5 DDCs which are populated with their own queries, and onSubmit 
uses only one of them, ideally, I would want the framework to do this:

1. Handle event
1.a. Trigger onSubmit
1.b. onSubmit accesses one of the DDCs' getObject.
1.c. The LDM is not loaded, so getObject delegates to load
1.d. load fires a query.                                        <- 1 query.
1.e. onSubmit logic finishes.
1.f. Wicket detaches all models, causing our LDM to get unloaded.
2. Render page
2.a. The DDCs get rendered.
2.b. The DDCs invoke their respective models' getObject
2.c. The LDMs are not loaded, so their getObjects delegate to load
2.d. loads fire queries.                                        <- 5 queries.
2.e. The DDCs render using the model data.
2.f. Wicket detaches all models post-render, causing our LDMs to get unloaded.

I count only 6 queries.  And when onSubmit does nothing, only 5.  Exactly the 
same as if 1.f didn't happen.

Now, from what you say I assume Wicket actually force-loads all models during 
phase 1, somewhere.  Probably when handling the parameters submitted by the 
form before 1.a.  All I'm asking here is whether perhaps we should make this 
process more lazy and postpone it to 1.b/c, so that we don't force-load all 
models, regardless of whether they're going to be used during event processing, 
but only do so for models that are actually used by the event handling.

If I'm making any serious wrong assumptions about the way wicket works, please 
detail them extensively so I may understand better.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Reply via email to