On Fri, Nov 20, 2015 at 5:02 PM, Sven Meier <s...@meiers.net> wrote: > > When a nested form is submitted Wicket calls the processing methods > > only for the nested form. > > I don't see a reason why #inputChanged() should be an exception. > > The outer form is not processed, because we don't want validation errors > to appear. #inputChanged() is called, so that on a possible render of the > whole page the input of the user is preserved.
This is what I said in my mail earlier. I suggest: 1) call form processing methods only for the submitted form (and the ones which requests processing explicitly, i.e. #wantSubmitOnNestedFormSubmit() and #wantSubmitOnParentFormSubmit()) 2) if the application needs to repaint any form which is not processed then the application has to call #inputChanged() for this form / form component The current way is: 1) call #inputChanged() for *all* 2) call other processing methods only for the submitted one and the extra ones which explicitly want to participate 3) the application should call #clearInput() for any non-processed For me the approach I suggest is more consistent and expected. > > > it is very common to reuse components in Wicket > > I'm shocked ;) > > > So a Panel with a Form could appear as a nested anywhere. > > That is the main reason to support nested forms. > > Yes, and it comes with a price. In most cases it's not necessary to > include a form in panels - generally I would advice against it: > - because "it's not supported in HTML" > - again, it comes with a price (see above) > > Have fun > Sven > > > > > > On 20.11.2015 16:47, Martin Grigorov wrote: > >> On Fri, Nov 20, 2015 at 4:37 PM, Sven Meier <s...@meiers.net> wrote: >> >> IMO the current behavior is wrong. >>>> >>> >>> I don't see anything wrong with the current nested form handling. Care to >>> elaborate? >>> >>> >> The problem I see is that Wicket treats #inputChanged() differently than >> all other Form processing methods (like #validate(), #on[In]Valid(), >> #updateModel()). >> When a nested form is submitted Wicket calls the processing methods only >> for the nested form. >> I don't see a reason why #inputChanged() should be an exception. >> >> >> >>> It's rather unusual to have to formComponents for the same model on a >>> single page. >>> >>> IMHO Patrick shouldn't use nested forms in the first place, I consider >>> them an advanced feature. >>> >>> >> Advanced or not, it is very common to reuse components in Wicket. >> So a Panel with a Form could appear as a nested anywhere. That is the main >> reason to support nested forms. >> >> >> >>> Regards >>> Sven >>> >>> >>> >>> >>> On 20.11.2015 16:06, Martin Grigorov wrote: >>> >>> OK. I see what happens. >>>> At >>>> >>>> org.apache.wicket.markup.html.form.Form#onFormSubmitted(org.apache.wicket.markup.html.form.IFormSubmitter) >>>> Wicket calls #inputChanged() for the root form, so this calls >>>> #inputChanged() on *all* FormComponents (including nested ones). >>>> My first reaction is: this is a bug! >>>> But then ... the purpose of the rawInput is to preserve the data entered >>>> by >>>> the user. So if your #onSubmit() logic in the nested form / submitter >>>> repaints the form components in the root/parent form then their data >>>> would >>>> be lost and the user will have to re-type it again. >>>> >>>> It seems in both cases the application developer will have to do >>>> something: >>>> 1) either clear the input manually (as now) >>>> 2) or update it manually when needed (by calling #inputChanged() only on >>>> the FormComponents in the rootForm). >>>> >>>> IMO the current behavior is wrong. >>>> >>>> Please create a bug with a quickstart. >>>> >>>> Martin Grigorov >>>> Wicket Training and Consulting >>>> https://twitter.com/mtgrigorov >>>> >>>> On Fri, Nov 20, 2015 at 3:51 PM, Patrick Davids < >>>> patrick.dav...@nubologic.com> wrote: >>>> >>>> Hi Martin, >>>> >>>>> this is true for my DropDownChoice2. >>>>> But DropDownChoice1 does not get validated. >>>>> So, this could be the reason why it is not cleared. >>>>> >>>>> Now... I'm getting more and more confused... *lol* >>>>> >>>>> >>>>> Page >>>>> Form A >>>>> DropDownChoice1 displaying selected 'Car 1' >>>>> Form B >>>>> DropDownChoice2 displaying selected 'Car 1' >>>>> >>>>> Patrick >>>>> >>>>> >>>>> >>>>> Am 20.11.2015 um 15:32 schrieb Martin Grigorov: >>>>> >>>>> Hi, >>>>> >>>>>> >>>>>> On Fri, Nov 20, 2015 at 3:22 PM, Patrick Davids < >>>>>> patrick.dav...@nubologic.com> wrote: >>>>>> >>>>>> Hi Sven, >>>>>> >>>>>> >>>>>>> using clearInput() works. >>>>>>> I call it in onConfigure() of my DropDownChoice. >>>>>>> >>>>>>> Ok, so far... but I'm still confused about the raw-input-handling. >>>>>>> >>>>>>> Ususally, (and thats what I have in mind): components reflect the >>>>>>> current >>>>>>> model objects state. >>>>>>> >>>>>>> Whats the reason saving the raw-input and determining the selected >>>>>>> value >>>>>>> by raw-input and not by the model-objects value? >>>>>>> >>>>>>> >>>>>>> Wicket clears the rawInput >>>>>>> >>>>>> at org.apache.wicket.markup.html.form.FormComponent#valid(). >>>>>> FormComponent#valid() is called if the validation and conversion pass >>>>>> successfully. >>>>>> You can put a breakpoint and see what happens. >>>>>> >>>>>> >>>>>> >>>>>> kind regards >>>>>> >>>>>>> Patrick >>>>>>> >>>>>>> >>>>>>> Am 19.11.2015 um 16:43 schrieb Sven Meier: >>>>>>> >>>>>>> Hi Patrick, >>>>>>> >>>>>>> >>>>>>>> so you have two components using the same model? Interesting. >>>>>>>> >>>>>>>> Easiest solution would be to clear the rawInput on DropDownChoice1: >>>>>>>> >>>>>>>> choice1.clearInput(); >>>>>>>> >>>>>>>> If you don't have access to the dropDown from your submitting code, >>>>>>>> you >>>>>>>> might use component events to signal the car selection: >>>>>>>> >>>>>>>> (Wicket events infrastructure) >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> https://ci.apache.org/projects/wicket/guide/6.x/guide/advanced.html#advanced_2 >>>>>>>> >>>>>>>> >>>>>>>> Have fun >>>>>>>> Sven >>>>>>>> >>>>>>>> >>>>>>>> On 19.11.2015 13:40, Patrick Davids wrote: >>>>>>>> >>>>>>>> Hi Wicket Pros, >>>>>>>> >>>>>>>> >>>>>>>>> I have a quite special case here and a question concerning nested >>>>>>>>> form >>>>>>>>> submits and FormComponent/Raw-Input Handling. >>>>>>>>> >>>>>>>>> This is my component tree: >>>>>>>>> >>>>>>>>> Page >>>>>>>>> Form A >>>>>>>>> DropDownChoice1 displaying selected 'Car 1' >>>>>>>>> Form B >>>>>>>>> DropDownChoice2 displaying selected 'Car 1' >>>>>>>>> >>>>>>>>> The model-binding of both DropDownChoices pointing to the same >>>>>>>>> member >>>>>>>>> of >>>>>>>>> the model-object of the page. >>>>>>>>> >>>>>>>>> This is my case and code flow: >>>>>>>>> - Someone uses DropDownChoice2 of Form B and changes the value to >>>>>>>>> 'Car >>>>>>>>> 2' >>>>>>>>> - Form B does a form submit >>>>>>>>> - Method onFormSubmitted(IFormSubmitter submitter) of Form A is >>>>>>>>> also >>>>>>>>> called >>>>>>>>> - which calls inputChanged() of the DropDownChoice1 (by visiting / >>>>>>>>> iteration) >>>>>>>>> - so DropDownChoice1.inputChanged() reads and sets its rawInput to >>>>>>>>> the >>>>>>>>> current displayed value 'Car 1' >>>>>>>>> - after form submit is done, an ajax refresh updates Form A >>>>>>>>> - DropDownChoice1 re-renders an runs through its appendOptionHtml() >>>>>>>>> - this reads getValue(), returning 'Car 1' from its previously >>>>>>>>> saved >>>>>>>>> rawInput >>>>>>>>> - after the ajax refresh is finished, Form A shows the old selected >>>>>>>>> 'Car >>>>>>>>> 1' instead of 'Car 2' >>>>>>>>> >>>>>>>>> Model-Object updates are working fine... but DropDownChoice1 does >>>>>>>>> not >>>>>>>>> reflect it correct, due to the raw-input-handling. >>>>>>>>> >>>>>>>>> Can someone help here, please? >>>>>>>>> >>>>>>>>> Thanx a lot >>>>>>>>> kind regards >>>>>>>>> Patrick >>>>>>>>> >>>>>>>>> >>>>>>>>> --------------------------------------------------------------------- >>>>>>>>> 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 > >
