Hi Martin,
>The modelObject should be the one before the form submit,
it should be the same one which all nested formComponents are changing.
I can't think of a case where this shouldn't hold.
>Because Form#updateModels() is called after the conversion and
validations.
>By calling the line above you basically ignore the submitted parameters.
The containing 'normal' formComponents have written the parameters into
their models, which are changing properties of the 'main' modelObject.
For the FormComponentPanel the following is a noop:
setConvertedInput(getModelObject());
...
updateModel();
I'm doing it this way, because the formComponentPanel hasn't anything to
convert actually, its model object stays the same.
Regards
Sven
On 12.02.2016 17:44, Martin Grigorov wrote:
Hi Sven,
On Fri, Feb 12, 2016 at 12:08 PM, Sven Meier <[email protected]> wrote:
Hi,
Is it a good idea to implement such a case extending FormComponentPanel,
or is FormComponentPanel for other purposes?
usuallly a FormComponentPanel is used when you want to combine the input
of several formComponents into a single model object, e.g.
MultiFileUploadField and DateTimeField.
But you can also use it for validation of whole model objects:
PersonPanel extends FormComponentPanel {
protected void convertInput() {
// converter input is just the current model object
setConvertedInput(getModelObject();
The modelObject should be the one before the form submit, no? Because
Form#updateModels() is called after the conversion and validations.
By calling the line above you basically ignore the submitted parameters.
I am missing something in your idea. What is it?
}
}
Form f = new Form(...);
PersonPanel personPanel = new PersonPanel(...)
personPanel.add(new XYValidator()); // <-- a validator that validates the
'converted' person
f.add(personPanel);
Have fun
Sven
On 12.02.2016 11:17, Patrick Davids wrote:
Hi all,
I would like to implement some kind of modular form components.
So, a developer is able stick together a form to save e.g. person data
and adress data with different panels containing the particular needed
input fields (textfield, selectboxes etc).
Form f = new Form(...);
f.add(new PersonFormComponentPanel(...));
f.add(new AddressFormComponentPanel(...));
Both, PersonFormComponentPanel and AddressFormComponentPanel are simple
panels, now, and it is working so far.
Now, I have a special use-case, which needs to add an
AbstractFormValidator to the form.
Not to bypass the inner required textfields validations of
PersonFormComponentPanel, I can implement
FormComponent<?>[] getDependentFormComponents(){...}
of the AbstractFormValidator.
BUT, it requieres to return FormComponents, not simple panels.
So, my idea was, just changing the implementation of
PersonFormComponentPanel extends Panel to PersonFormComponentPanel extends
FormComponentPanel, so the entire PersonFormComponentPanel acts as
FormComponent to be able to fullfill the FormComponent<?>[]
getDependentFormComponents(){...} return value.
Unfortunately this is not working, and I dont know why...
My getInnerMostModel() of the PropertyResolver is always null and the
formcomponents model-update does not succeed / WicketRuntimeException.
Maybe it has something todo with the need to implement
setConvertedInput() / getConvertedInput() which is mentioned in the javadoc
of FormComponentPanel?
I'm not sure about that... maybe someone can help here?
So... these are my questions:
Is it a good idea to implement such a case extending FormComponentPanel,
or is FormComponentPanel for other purposes?
How can I achieve the binding of the dependend formcomponents to the
AbstractFormValidator, without exposing the inner formcomponents of the
PersonFormComponentPanel by providing a method like
PersonFormComponentPanel.getAllInnerFormComponents()?
Am I able to keep the idea of extending FormComponentPanel by
implementing getConvertedInput(), but how to to that right?
Thanx a lot for help
kind regards
Parick
---------------------------------------------------------------------
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]
