Fair.  To make this work, Wicket would need to get the chance to intervene in 
every model's getObject so that it can perform its lazy operation if necessary.

On 29 Oct 2011, at 18:21, Igor Vaynberg wrote:

> because there is no way to know if the user will access the model
> object or not. eg if i use a property model to bind my form component
> to a field then there is no way for me to know if that field is
> accessed during a formsubmit or not, thus all form components always
> push their data.
> 
> -igor
> 
> On Sat, Oct 29, 2011 at 8:49 AM, Maarten Billemont <lhun...@lyndir.com> wrote:
>> 
>> On 29 Oct 2011, at 17:14, Bertrand Guay-Paquet wrote:
>> 
>>> My understanding is that the queries need to be run in order to get the 
>>> choice lists of the DDCs. Even if onSubmit uses only one of the DDC's 
>>> model, the DDCs still need to convert their input.
>> 
>> And my point is; why are we converting input to set model objects that we 
>> don't access?  Perhaps we should make this process more lazy, and save in 
>> queries that way.  That makes the whole reason to keep the currently broken 
>> solution in effect null and void.
>> 
>>> 
>>> On 29/10/2011 4:40 AM, Maarten Billemont wrote:
>>>> 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
>>>> 
>>>> 
>>> 
>>> ---------------------------------------------------------------------
>>> 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

Reply via email to