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]
