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 <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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
