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: [email protected] For additional commands, e-mail: [email protected]
