You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Joseph Pachod <jo...@thomas-daily.de> on 2010/04/29 00:24:53 UTC
AjaxFormComponentUpdatingBehavior breaking wicket's convention ? Which alternatives then?
hi
I was quite surprised, recently, by the AjaxFormComponentUpdatingBehavior, which directly updates the model. At the time it seemed pretty odd but I moved on.
then I recently read this article from Igor, Building a ListEditor form component (http://wicketinaction.com/2008/10/building-a-listeditor-form-component/comment-page-1/) which states "in order to be a good citizen in Wicket’s form processing" a component should "Implement atomic form updates – this is perhaps the most important feature. If the user moves an item up or down in the list this change should not be reflected in the model object until the form is submitted."
However, the AjaxFormComponentUpdatingBehavior completely breaks this important aspect, by going directly at the model. Furthermore, the javadoc doesn't illustrate how dangerous it is. For example, setting setDefaultFormProcessing on some cancel button won't work anymore. Neither does the javadoc hint at some ways to avoid this.
Among the way to avoid this, I currently mostly see the AjaxFormValidatingBehavior or writing an ad hoc form component copying his initial state and implementing IFormModelUpdateListener.
Thinking back on my initial issue, a Behavior which would only update the input of the component would have been resolved it (issue was a listview where adding a line would loose non submitted input on textfields).
A such "AjaxFormComponentConvertingBehavior" is in fact easy to do, it's a copy of AjaxFormComponentUpdatingBehavior with a shortened onEvent:
@Override
protected final void onEvent(final AjaxRequestTarget target) {
final FormComponent<?> formComponent = getFormComponent();
if (getEvent().toLowerCase().equals("onblur") && disableFocusOnBlur()) {
target.focusComponent(null);
}
try {
formComponent.inputChanged();
onUpdate(target);
} catch (RuntimeException e) {
onError(target, e);
}
}
Such a behavior would resolve some of the use case currently "wrongly" addressed by the AjaxFormComponentUpdatingBehavior. It could even be its parent class and be spoken of in its javadoc.
What your feelings on that ?
sorry for this long post and thanks in advance for your answers (which most likely will show I've missed something obvious there!).
++
joseph
Re: AjaxFormComponentUpdatingBehavior breaking wicket's convention ?
Which alternatives then?
Posted by Jeremy Thomerson <je...@wickettraining.com>.
I'm not sure I understand what your problem with this component is. The
component is designed to mimic the entire submit process for a single
component. It says this in the javadoc: "This behavior encapsulates the
entire form-processing workflow as relevant only to this component". It
also warns you that the model will be updated: "so if validation is
successful the component's model will be updated according to the submitted
value"
The key is that it does validation, etc, just like a form submit would do.
It just does it on a local (i.e. single component) level rather than for
the entire form. If you don't want the model updated,
override getUpdateModel() and return false.
--
Jeremy Thomerson
http://www.wickettraining.com
On Wed, Apr 28, 2010 at 5:24 PM, Joseph Pachod <josephpachod@thomas-daily.de
> wrote:
>
> hi
>
> I was quite surprised, recently, by the AjaxFormComponentUpdatingBehavior,
> which directly updates the model. At the time it seemed pretty odd but I
> moved on.
>
> then I recently read this article from Igor, Building a ListEditor form
> component (
> http://wicketinaction.com/2008/10/building-a-listeditor-form-component/comment-page-1/)
> which states "in order to be a good citizen in Wicket’s form processing" a
> component should "Implement atomic form updates – this is perhaps the most
> important feature. If the user moves an item up or down in the list this
> change should not be reflected in the model object until the form is
> submitted."
>
> However, the AjaxFormComponentUpdatingBehavior completely breaks this
> important aspect, by going directly at the model. Furthermore, the javadoc
> doesn't illustrate how dangerous it is. For example, setting
> setDefaultFormProcessing on some cancel button won't work anymore. Neither
> does the javadoc hint at some ways to avoid this.
>
> Among the way to avoid this, I currently mostly see the
> AjaxFormValidatingBehavior or writing an ad hoc form component copying his
> initial state and implementing IFormModelUpdateListener.
>
> Thinking back on my initial issue, a Behavior which would only update the
> input of the component would have been resolved it (issue was a listview
> where adding a line would loose non submitted input on textfields).
>
> A such "AjaxFormComponentConvertingBehavior" is in fact easy to do, it's a
> copy of AjaxFormComponentUpdatingBehavior with a shortened onEvent:
> @Override
> protected final void onEvent(final AjaxRequestTarget target) {
> final FormComponent<?> formComponent = getFormComponent();
>
> if (getEvent().toLowerCase().equals("onblur") &&
> disableFocusOnBlur()) {
> target.focusComponent(null);
> }
>
> try {
> formComponent.inputChanged();
> onUpdate(target);
> } catch (RuntimeException e) {
> onError(target, e);
>
> }
> }
>
> Such a behavior would resolve some of the use case currently "wrongly"
> addressed by the AjaxFormComponentUpdatingBehavior. It could even be its
> parent class and be spoken of in its javadoc.
>
> What your feelings on that ?
>
> sorry for this long post and thanks in advance for your answers (which most
> likely will show I've missed something obvious there!).
>
> ++
> joseph
>
Re: AjaxFormComponentUpdatingBehavior breaking wicket's convention
? Which alternatives then?
Posted by Douglas Ferguson <do...@douglasferguson.us>.
I use it all the time.
In order to get the cancel button and back buttons to work, I do of these things:
1) I back my model with an evicted hibernate proxy, and I only save the proxy when the user submits the form. Therefore any change made to the model are transient unless i specifically persist.
2) I back my model with a custom model object specifically for the form, when the form is submitted I copy the values to my persisted object. If they hit cancel then I reload a new model object, or clear the current one...
On Apr 28, 2010, at 5:24 PM, Joseph Pachod wrote:
>
> hi
>
> I was quite surprised, recently, by the AjaxFormComponentUpdatingBehavior, which directly updates the model. At the time it seemed pretty odd but I moved on.
>
> then I recently read this article from Igor, Building a ListEditor form component (http://wicketinaction.com/2008/10/building-a-listeditor-form-component/comment-page-1/) which states "in order to be a good citizen in Wicket’s form processing" a component should "Implement atomic form updates – this is perhaps the most important feature. If the user moves an item up or down in the list this change should not be reflected in the model object until the form is submitted."
>
> However, the AjaxFormComponentUpdatingBehavior completely breaks this important aspect, by going directly at the model. Furthermore, the javadoc doesn't illustrate how dangerous it is. For example, setting setDefaultFormProcessing on some cancel button won't work anymore. Neither does the javadoc hint at some ways to avoid this.
>
> Among the way to avoid this, I currently mostly see the AjaxFormValidatingBehavior or writing an ad hoc form component copying his initial state and implementing IFormModelUpdateListener.
>
> Thinking back on my initial issue, a Behavior which would only update the input of the component would have been resolved it (issue was a listview where adding a line would loose non submitted input on textfields).
>
> A such "AjaxFormComponentConvertingBehavior" is in fact easy to do, it's a copy of AjaxFormComponentUpdatingBehavior with a shortened onEvent:
> @Override
> protected final void onEvent(final AjaxRequestTarget target) {
> final FormComponent<?> formComponent = getFormComponent();
>
> if (getEvent().toLowerCase().equals("onblur") && disableFocusOnBlur()) {
> target.focusComponent(null);
> }
>
> try {
> formComponent.inputChanged();
> onUpdate(target);
> } catch (RuntimeException e) {
> onError(target, e);
>
> }
> }
>
> Such a behavior would resolve some of the use case currently "wrongly" addressed by the AjaxFormComponentUpdatingBehavior. It could even be its parent class and be spoken of in its javadoc.
>
> What your feelings on that ?
>
> sorry for this long post and thanks in advance for your answers (which most likely will show I've missed something obvious there!).
>
> ++
> joseph
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org