> 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.

> 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]

Reply via email to