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
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 Sa
Models are loaded when needed only, they're lazy.
why are we converting input to set model objects that we don't access?
A form submit involves (accesses) all nested form components.
Sven
On 10/29/2011 05:49 PM, Maarten Billemont wrote:
On 29 Oct 2011, at 17:14, Bertrand Guay-Paquet wrote:
I did a little more research before changing my code and found other
problematic cases which, I think, deserve mention.
Methodology: ran the regex "get(?:model)?object\(\)" on wicket 1.5
source and inspected the results.
Some results:
1-Component#setDefaultModelObject(final Object) makes this
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 in
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.
On 29/10/2011 4:40 AM, Maarten Billemont wrote:
On 28 Oct 2011, at 17:52, Igor Vaynberg wrote:
and
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
Thanks for clearing that up. I didn't know it was considered bad
practice to access _any_ model's object before rendering. In that case,
my points are moot (but I have some code I must change...)
I wasn't only trying to build an impossible example btw :) It was pretty
close to what I intended
i suppose you can contrive an example that breaks any situation :)
in this case you are making a lot of assumptions: the two panels are
not sharing a model even though they are both referencing the same
person, the show panel loads the model prematurely instead of at
render time. these two things
On 28/10/2011 12:49 PM, Igor Vaynberg wrote:
i think you are blowing this way out of proportion.
I hope so :)
this only affects components that (A) modify their own model but do
not update it and *also* (B) have their model loaded for some reason
before they update it.
This is not the type of s
i think you are blowing this way out of proportion.
this only affects components that (A) modify their own model but do
not update it and *also* (B) have their model loaded for some reason
before they update it.
(B) is very rare - thats why this very rarely causes a problem.
we have always adver
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
On Fri, Oct 28, 2011 at 8:10 AM, Bertrand Guay-Paquet
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 t
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 m
our 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
ith lists,
which your database tables are not. if you dont want to run into this
then use a dataview or a datatable.
-igor
>
>>
>> HTH
>> Sven
>>
>> -----Ursprüngliche Nachricht-
>> Von: Maarten Billemont [mailto:lhun...@lyndir.com]
>> Gesendet: Mittwo
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 201
On 26 Oct 2011, at 11:57, Wilhelmsen Tor Iver wrote:
>> 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
>> render
> 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.
That's nearly "always" - then you are just as
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 separ
20 matches
Mail list logo
