Hi Andrea, Thanks for this investigation, this is very interesting that nothing breaks!
> I don't understand why the onFormSubmitted is called on the root form and not on the actually submitted one The question is "what form is really submitted/posted"? We know that only a real form - the root form - can/will be submitted (using #submit()). So from my understanding, .getRootForm().onFormSubmitted() had the purpose to match the real submitted form, not an inner - fake - form... But IIRC, wicket is smart enough to recognize an inner-form as the form being submitted. I don't have deeply tested like you did, but if we can remove the call to getRootForm(), I'm +1! :) Best regards, Sebastien On Sun, Nov 22, 2015 at 7:37 PM, Andrea Del Bene <[email protected]> wrote: > Hi, > > playing with the quickstart I've noticed something strange that might help > to solve this issue. Before rendering phase both the inner and outer form > are marked as submitted (Form#isSubmitted returns true). This is quite > strange as I would expect that only the inner form would be marked as > submitted. It turned out that the cause of this strange behavior is > AjaxFormSubmitBehavior#onEvent which just contains: > > getForm().getRootForm().onFormSubmitted(new AjaxFormSubmitter(this, > target)); > > I don't understand why the onFormSubmitted is called on the root form and > not on the actually submitted one. If we remove getRootForm() the issue is > resolved and no test gets broken. The call to getRootForm() was introduced > ages ago for WICKET-1282 but the issue doesn't provide much details about > it. > > Andrea. > > Hi, >> >> > 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 >> >> this will break current applications. >> >> We can argue which approach is more consistent, but I don't think we >> should change this just because of a single user request: >> His solution is to not using nested forms. >> >> Regards >> Sven >> >> >> >> >> On 20.11.2015 17:13, Martin Grigorov wrote: >> >>> On Fri, Nov 20, 2015 at 5:02 PM, Sven Meier <[email protected]> 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 <[email protected]> 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 < >>>>>>> [email protected]> 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 < >>>>>>>>> [email protected]> 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: [email protected] >>>>>>>>>>>> For additional commands, e-mail: [email protected] >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> --------------------------------------------------------------------- >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> To unsubscribe, e-mail: [email protected] >>>>>>>>>>>> >>>>>>>>>>> For additional commands, e-mail: [email protected] >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> --------------------------------------------------------------------- >>>>>>> >>>>>>> >>>>>> To unsubscribe, e-mail: [email protected] >>>>>> For additional commands, e-mail: [email protected] >>>>>> >>>>>> >>>>>> >>>>>> >>>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>>> >>>> >>> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
