Re: LDMs load too early - hold outdated application data.
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 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
Re: LDMs load too early - hold outdated application data.
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 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
Re: LDMs load too early - hold outdated application data.
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: 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
Re: LDMs load too early - hold outdated application data.
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 call
"getModelComparator().compare(this, object)" which does
getDefaultModelObject()
2-FormComponent#updateCollectionModel(FormComponent>)
calls formComponent.getModelObject()
3-ListMultipleChoice#convertChoiceIdsToChoices and
AbstractSingleSelectChoice#convertChoiceIdToChoice use
AbstractChoice#getChoices() which calls choices.getObject()
4-FormComponent.MessageSource#getLabel() calls fc.getLabel().getObject()
and is used when building an error message
[1] and [2] relate to FormComponent model update which can clearly
trigger the load of LDMs which can be out of date after form processing.
[3] is for input conversion and can also leave some out of date LDMs
attached after form processing.
For [4], imagine a case where the label (a custom model) of a form
component references the name of a person (property model) which is
fetched from a LDM of a person. Granted, usually when there is an error
message for a form component, the whole form does nothing. However, as
AjaxFallbackButton shows, there can still be some processing happening
in onError(AjaxRequestTarget target, Form form).
I haven't found this pattern in Wicket's source, but consider also
validators. They can also need to access some LDMs for validation and I
don't think this is bad practice. The fix for this is to require
validators to explicitly detach the models they use for validation, but
I would argue that it wasn't historically necessary and is easy to forget
All this amounts to a lot of stuff to detach manually and I probably
missed other cases as well. Also, this affects stateful and stateless
pages since it is related to form processing.
Regards,
Bertrand
On 28/10/2011 5:04 PM, Bertrand Guay-Paquet wrote:
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 on doing and was wondering how to
solve these issues when Maarten started the thread.
Cheers,
Bertrand
On 28/10/2011 4:42 PM, Igor Vaynberg wrote:
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 are considered bad practice anyways.
if you wanted to solves this in a neat way you can use events.
updatepersonpanel can send out a PersonUpdated event and
ShowPersonPanel can listen for it and detach its model.
-igor
On Fri, Oct 28, 2011 at 1:15 PM, Bertrand Guay-Paquet
wrote:
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 situation I meant. What you describe is a clear
situation where the component doing the update can easily handle
detaching
its model for a refresh.
With a business layer and DTOs, doing the update correctly on the
wicket
model directly is impossible without replicating the business logic
in the
web client. That's why I say that the model can be detached and
refreshed
above and not just updated.
We could also argue that event handlers accessing model objects (see my
issue 1) should systematically detach all accessed models after their
processing to avoid stale models.
However, Issue 2 still remains. Here is a more detailed example to
illustrate it:
class PersonDto {
private int id;
// other fields and methods
}
class ShowPersonPanel extends Panel {
private int personId;
// other fields
MyPanel (IModel model) {
personId = model.getObject().getId(); // triggers load of LDM
// Pass model to other components + other stuff
}
}
class UpdatePersonPanel extends Panel {
// adds a component of type StatelessAjaxUpdatePersonLink
}
class StatelessAjaxUpdatePersonLink extends Link {
private IModel personModel;
onClick(AjaxRequestTarget target) {
updateSomePersonAttribute(personModel);
personModel.detach();
target.add(this);
}
}
Consider a stateless page with a ShowPersonPanel and an
UpdatePersonPanel.
Further, when the StatelessAjaxUpdatePersonLink is clicked, the
ShowPersonPanel is added to the request target by other code.
Sequence of events for stateless ajax request:
1-New page instance created with ShowPersonPanel a
Re: LDMs load too early - hold outdated application data.
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
Re: LDMs load too early - hold outdated application data.
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 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
Re: LDMs load too early - hold outdated application data.
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
Re: LDMs load too early - hold outdated application data.
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 on doing and was wondering how to solve these
issues when Maarten started the thread.
Cheers,
Bertrand
On 28/10/2011 4:42 PM, Igor Vaynberg wrote:
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 are considered bad practice anyways.
if you wanted to solves this in a neat way you can use events.
updatepersonpanel can send out a PersonUpdated event and
ShowPersonPanel can listen for it and detach its model.
-igor
On Fri, Oct 28, 2011 at 1:15 PM, Bertrand Guay-Paquet
wrote:
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 situation I meant. What you describe is a clear
situation where the component doing the update can easily handle detaching
its model for a refresh.
With a business layer and DTOs, doing the update correctly on the wicket
model directly is impossible without replicating the business logic in the
web client. That's why I say that the model can be detached and refreshed
above and not just updated.
We could also argue that event handlers accessing model objects (see my
issue 1) should systematically detach all accessed models after their
processing to avoid stale models.
However, Issue 2 still remains. Here is a more detailed example to
illustrate it:
class PersonDto {
private int id;
// other fields and methods
}
class ShowPersonPanel extends Panel {
private int personId;
// other fields
MyPanel (IModel model) {
personId = model.getObject().getId(); // triggers load of LDM
// Pass model to other components + other stuff
}
}
class UpdatePersonPanel extends Panel {
// adds a component of type StatelessAjaxUpdatePersonLink
}
class StatelessAjaxUpdatePersonLink extends Link {
private IModel personModel;
onClick(AjaxRequestTarget target) {
updateSomePersonAttribute(personModel);
personModel.detach();
target.add(this);
}
}
Consider a stateless page with a ShowPersonPanel and an UpdatePersonPanel.
Further, when the StatelessAjaxUpdatePersonLink is clicked, the
ShowPersonPanel is added to the request target by other code.
Sequence of events for stateless ajax request:
1-New page instance created with ShowPersonPanel and UpdatePersonPanel, not
sharing the same IModel instance for some reason. Note that the
constructor of ShowPersonPanel triggers the load of its PersonDto LDM.
2-Ajax link listener is invoked which updates the persistent Person and
detaches the now stale model
3-ShowPersonPanel is added to the ajax target (through events perhaps)
4-ShowPersonPanel and UpdatePersonPanel are rendered. ShowPersonPanel has
stale LDM and UpdatePersonPanel has fresh LDM.
I don't see how to manage this without either A) a blanket detach() of all
models or B) some complicated panel and model inter-dependency management.
Note that this sequence of events is not the same for stateful pages. The
stateful pages do not construct a new page instance before invoking the link
listener so no outside LDMs are loaded.
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
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: LDMs load too early - hold outdated application data.
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 are considered bad practice anyways.
if you wanted to solves this in a neat way you can use events.
updatepersonpanel can send out a PersonUpdated event and
ShowPersonPanel can listen for it and detach its model.
-igor
On Fri, Oct 28, 2011 at 1:15 PM, Bertrand Guay-Paquet
wrote:
> 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 situation I meant. What you describe is a clear
> situation where the component doing the update can easily handle detaching
> its model for a refresh.
>
> With a business layer and DTOs, doing the update correctly on the wicket
> model directly is impossible without replicating the business logic in the
> web client. That's why I say that the model can be detached and refreshed
> above and not just updated.
>
> We could also argue that event handlers accessing model objects (see my
> issue 1) should systematically detach all accessed models after their
> processing to avoid stale models.
>
> However, Issue 2 still remains. Here is a more detailed example to
> illustrate it:
> class PersonDto {
> private int id;
> // other fields and methods
> }
>
> class ShowPersonPanel extends Panel {
> private int personId;
> // other fields
>
> MyPanel (IModel model) {
> personId = model.getObject().getId(); // triggers load of LDM
> // Pass model to other components + other stuff
> }
> }
>
> class UpdatePersonPanel extends Panel {
> // adds a component of type StatelessAjaxUpdatePersonLink
> }
>
> class StatelessAjaxUpdatePersonLink extends Link {
> private IModel personModel;
>
> onClick(AjaxRequestTarget target) {
> updateSomePersonAttribute(personModel);
> personModel.detach();
> target.add(this);
> }
> }
>
> Consider a stateless page with a ShowPersonPanel and an UpdatePersonPanel.
> Further, when the StatelessAjaxUpdatePersonLink is clicked, the
> ShowPersonPanel is added to the request target by other code.
>
> Sequence of events for stateless ajax request:
> 1-New page instance created with ShowPersonPanel and UpdatePersonPanel, not
> sharing the same IModel instance for some reason. Note that the
> constructor of ShowPersonPanel triggers the load of its PersonDto LDM.
> 2-Ajax link listener is invoked which updates the persistent Person and
> detaches the now stale model
> 3-ShowPersonPanel is added to the ajax target (through events perhaps)
> 4-ShowPersonPanel and UpdatePersonPanel are rendered. ShowPersonPanel has
> stale LDM and UpdatePersonPanel has fresh LDM.
>
> I don't see how to manage this without either A) a blanket detach() of all
> models or B) some complicated panel and model inter-dependency management.
>
> Note that this sequence of events is not the same for stateful pages. The
> stateful pages do not construct a new page instance before invoking the link
> listener so no outside LDMs are loaded.
>
> 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
Re: LDMs load too early - hold outdated application data.
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 situation I meant. What you describe is a clear
situation where the component doing the update can easily handle
detaching its model for a refresh.
With a business layer and DTOs, doing the update correctly on the wicket
model directly is impossible without replicating the business logic in
the web client. That's why I say that the model can be detached and
refreshed above and not just updated.
We could also argue that event handlers accessing model objects (see my
issue 1) should systematically detach all accessed models after their
processing to avoid stale models.
However, Issue 2 still remains. Here is a more detailed example to
illustrate it:
class PersonDto {
private int id;
// other fields and methods
}
class ShowPersonPanel extends Panel {
private int personId;
// other fields
MyPanel (IModel model) {
personId = model.getObject().getId(); // triggers load of LDM
// Pass model to other components + other stuff
}
}
class UpdatePersonPanel extends Panel {
// adds a component of type StatelessAjaxUpdatePersonLink
}
class StatelessAjaxUpdatePersonLink extends Link {
private IModel personModel;
onClick(AjaxRequestTarget target) {
updateSomePersonAttribute(personModel);
personModel.detach();
target.add(this);
}
}
Consider a stateless page with a ShowPersonPanel and an
UpdatePersonPanel. Further, when the StatelessAjaxUpdatePersonLink is
clicked, the ShowPersonPanel is added to the request target by other code.
Sequence of events for stateless ajax request:
1-New page instance created with ShowPersonPanel and UpdatePersonPanel,
not sharing the same IModel instance for some reason. Note
that the constructor of ShowPersonPanel triggers the load of its
PersonDto LDM.
2-Ajax link listener is invoked which updates the persistent Person and
detaches the now stale model
3-ShowPersonPanel is added to the ajax target (through events perhaps)
4-ShowPersonPanel and UpdatePersonPanel are rendered. ShowPersonPanel
has stale LDM and UpdatePersonPanel has fresh LDM.
I don't see how to manage this without either A) a blanket detach() of
all models or B) some complicated panel and model inter-dependency
management.
Note that this sequence of events is not the same for stateful pages.
The stateful pages do not construct a new page instance before invoking
the link listener so no outside LDMs are loaded.
Regards,
Bertrand
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: LDMs load too early - hold outdated application data.
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 advertised that we make no guarantees as to when the object's model is loaded. taking that into account it stands to reason that if you do something like this: Obect o=ddc.getmodelobject(); // or by implicitly using the object that this points to deleteFromDatabase(o); you should realize that you have touched the ddc, possibly dirtying its state and causing its lazy models to be loaded. you have also modified the ddc's state without letting it know. it is reasonable that you should be expected to synchronize this change: ddc.getchoices().remove(o); of course the easiest way to do that is to blanket ddc.detach(); it is also important to note that "other" models should not be effected because there is no reason for wicket to load them, so in the example of the "dashboard" everything should work fine. -igor On Fri, Oct 28, 2011 at 9:36 AM, Bertrand Guay-Paquet wrote: > >>> 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. > > While I don't dispute the claims about past problems, I think the new usages > and architecture of Wicket changes things. The 2 issues I noted above are > related to events (a new 1.5 feature, probably not used widely yet) and > stateless ajax (still not widely used as I understand it). > > With reusable components that can be inserted in any page, components that > update persistent state cannot determine if "getPage().detach();" should be > called; hence they have to resort to calling it systematically. > > Imagine a "dashboard" style stateless-ajax interface where the choice of > components is up to the user (like in JIRA) and some components can modify > state. These components would need to know in which context they are used to > decide whether to call "getPage().detach();" or not. Doesn't this defeat > some of the purpose of reusable components? > > 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
Re: LDMs load too early - hold outdated application data.
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. While I don't dispute the claims about past problems, I think the new usages and architecture of Wicket changes things. The 2 issues I noted above are related to events (a new 1.5 feature, probably not used widely yet) and stateless ajax (still not widely used as I understand it). With reusable components that can be inserted in any page, components that update persistent state cannot determine if "getPage().detach();" should be called; hence they have to resort to calling it systematically. Imagine a "dashboard" style stateless-ajax interface where the choice of components is up to the user (like in JIRA) and some components can modify state. These components would need to know in which context they are used to decide whether to call "getPage().detach();" or not. Doesn't this defeat some of the purpose of reusable components? Bertrand - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: LDMs load too early - hold outdated application data.
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 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
Re: LDMs load too early - hold outdated application data.
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. 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. Regards, Bertrand - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: LDMs load too early - hold outdated application data.
On 27 Oct 2011, at 17:18, Igor Vaynberg wrote: > On Thu, Oct 27, 2011 at 12:29 AM, Maarten Billemont > wrote: >> >> On 26 Oct 2011, at 12:14, Sven Meier wrote: >> >>> Hi, >>> >>>>> Or use a separate LDM for each of your list items >>>> I'm not sure I understand what you mean here. Could you illustrate? >>> >>> your LDM seems to return a list of items and you're iterating over them with >>> a ListView. Note that ListView uses a ListItemModel for each item: >> >> Fair. Though my actual use case is an LDM that populates a dropdown. >> >> There is only one button in the form to delete the dropdown's selected >> object, whose onSubmit uses the dropdown's model to determine what object to >> delete. >> >>>> It seems to me that Wicket should detach its models again after events >>>> have triggered, in addition to after rendering has >completed. That would >>>> resetthe state of all models to what the developer expects it to be before >>>> rendering begins. >>> >>> You can hook your own listener into Wicket (I*Listener) and detach the >>> models yourself. >> >> If we can think of no issues with this approach, I'd much rather vote to >> make it standard behavior in Wicket, so that >> developers can trust their models behave as they'd expect. > > 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. > so why should we have to reload the other four? imho it is a well > known fact that if you do something like this: > > List list=model.getobject(); > Foo foo=list.get(0); > removeFromDatabase(foo); > > we all understand that model.getobject() still returns an unchanged > list, so if you want a refreshed list you have to call model.detach(); I've never actually thought it necessary to invoke this method myself; I mostly considered it internal-use. But perhaps, yes, the developer should be aware of needing to do this maintenance. > > the core of your problem here is that you are using a ListView to > represent data in your 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'm using a DDC. And AFAIK this issue would also exist for eg. ListDataProvider. > > -igor > > >> >>> >>> 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 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 separate LDM for each of your list items: >>>> This way the LDM of the list is loaded for rendering *after* the event >>> only. >>>> Additionally the event won't crash when the list of users has changed >>> while >>>> the page is displayed. >>> >>> I'm not sure I understand what you mean here. Could you illustrate? >>> >>> >>> 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. >>> >>> >>>> >>
Re: LDMs load too early - hold outdated application data.
On Thu, Oct 27, 2011 at 12:29 AM, Maarten Billemont wrote: > > On 26 Oct 2011, at 12:14, Sven Meier wrote: > >> Hi, >> >>>> Or use a separate LDM for each of your list items >>> I'm not sure I understand what you mean here. Could you illustrate? >> >> your LDM seems to return a list of items and you're iterating over them with >> a ListView. Note that ListView uses a ListItemModel for each item: > > Fair. Though my actual use case is an LDM that populates a dropdown. > > There is only one button in the form to delete the dropdown's selected > object, whose onSubmit uses the dropdown's model to determine what object to > delete. > >>> It seems to me that Wicket should detach its models again after events have >>> triggered, in addition to after rendering has >completed. That would >>> resetthe state of all models to what the developer expects it to be before >>> rendering begins. >> >> You can hook your own listener into Wicket (I*Listener) and detach the >> models yourself. > > If we can think of no issues with this approach, I'd much rather vote to make > it standard behavior in Wicket, so that > developers can trust their models behave as they'd expect. 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 - so why should we have to reload the other four? imho it is a well known fact that if you do something like this: List list=model.getobject(); Foo foo=list.get(0); removeFromDatabase(foo); we all understand that model.getobject() still returns an unchanged list, so if you want a refreshed list you have to call model.detach(); the core of your problem here is that you are using a ListView to represent data in your 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. -igor > >> >> 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 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 separate LDM for each of your list items: >>> This way the LDM of the list is loaded for rendering *after* the event >> only. >>> Additionally the event won't crash when the list of users has changed >> while >>> the page is displayed. >> >> I'm not sure I understand what you mean here. Could you illustrate? >> >> >> 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. >> >> >>> >>> HTH >>> Sven >>> >>> -Ursprüngliche Nachricht- >>> Von: Maarten Billemont [mailto:lhun...@lyndir.com] >>> Gesendet: Mittwoch, 26. Oktober 2011 10:15 >>> An: users@wicket.apache.org >>> Betreff: LDMs load too early - hold outdated application data. >>> >>> 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. &
Re: LDMs load too early - hold outdated application data.
On 26 Oct 2011, at 12:14, Sven Meier wrote: > Hi, > >>> Or use a separate LDM for each of your list items >> I'm not sure I understand what you mean here. Could you illustrate? > > your LDM seems to return a list of items and you're iterating over them with > a ListView. Note that ListView uses a ListItemModel for each item: Fair. Though my actual use case is an LDM that populates a dropdown. There is only one button in the form to delete the dropdown's selected object, whose onSubmit uses the dropdown's model to determine what object to delete. >> It seems to me that Wicket should detach its models again after events have >> triggered, in addition to after rendering has >completed. That would >> resetthe state of all models to what the developer expects it to be before >> rendering begins. > > You can hook your own listener into Wicket (I*Listener) and detach the > models yourself. If we can think of no issues with this approach, I'd much rather vote to make it standard behavior in Wicket, so that developers can trust their models behave as they'd expect. > > 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 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 separate LDM for each of your list items: >> This way the LDM of the list is loaded for rendering *after* the event > only. >> Additionally the event won't crash when the list of users has changed > while >> the page is displayed. > > I'm not sure I understand what you mean here. Could you illustrate? > > > 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. > > >> >> HTH >> Sven >> >> -Ursprüngliche Nachricht- >> Von: Maarten Billemont [mailto:lhun...@lyndir.com] >> Gesendet: Mittwoch, 26. Oktober 2011 10:15 >> An: users@wicket.apache.org >> Betreff: LDMs load too early - hold outdated application data. >> >> 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 >> >> >> >> - >> To unsubscribe, e-mail: users-unsubscr...
Re: LDMs load too early - hold outdated application data.
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 >> rendering begins. > > That's nearly "always" - then you are just as well served with an > AbstractReadOnlyModel that loads data on every call to getObject()... :) If you claim that an LDM's use is limited to avoiding a load in between event handling and rendering of a page, that would make LDMs damn near useless. Luckily, this is simply not true. An LDM's main use is to avoid multiple loads when the model is accessed multiple times during rendering. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
RE: LDMs load too early - hold outdated application data.
> 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 well served with an AbstractReadOnlyModel that loads data on every call to getObject()... :) - Tor Iver - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: LDMs load too early - hold outdated application data.
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 separate LDM for each of your list items: > This way the LDM of the list is loaded for rendering *after* the event only. > Additionally the event won't crash when the list of users has changed while > the page is displayed. I'm not sure I understand what you mean here. Could you illustrate? 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. > > HTH > Sven > > -Ursprüngliche Nachricht- > Von: Maarten Billemont [mailto:lhun...@lyndir.com] > Gesendet: Mittwoch, 26. Oktober 2011 10:15 > An: users@wicket.apache.org > Betreff: LDMs load too early - hold outdated application data. > > 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 > > > > - > 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
