You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Patrick Davids <pa...@nubologic.com> on 2016/02/12 11:17:42 UTC
Question / Modular FormComponents / FormComponentPanels /
AbstractFormValidator and problems with model updates
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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Question / Modular FormComponents / FormComponentPanels /
AbstractFormValidator and problems with model updates
Posted by Martin Grigorov <mg...@apache.org>.
Hi,
I don't remember the last time I needed to write custom FCP so I don't
really understand how/why these code snippets would work the way you
explain.
I'll fire the debugger to see why they behave differently than the other
form components in the form submit processing.
Thanks!
On Feb 13, 2016 4:53 AM, "Joachim Schrod" <js...@acm.org> wrote:
> FWIW, for FormComponentPanels I often have an empty implementation
> of updateModel() and either have a wrapper method to add validators
> for those (abstract) sub-component, or redefine convertInput() to
> construct a proper object from
> nestedFormComponent.getConvertedInput() to make validators work on
> them.
>
> Works most of the time like a charm; except those 0.001% where I
> really need to have (a) a proper conversion/validation on the
> FormComponentPanel level and (b) full support of AJAX
> onchange-updates for the sub-components. Then it get's hairy... :-)
>
> Cheers,
> Joachim
>
> On 02/12/16 18:29, Sven Meier wrote:
> > Hi again,
> >
> > now I see what you meant:
> >
> > Yes, the converted values haven't been written yet.
> > I was writing my example off the top of my head :). Validators
> > won't help here, you'll have to do validation by hand instead:
> >
> > PersonPanel extends FormComponentPanel {
> > @Override
> > protected void convertInput() {
> > // converted input is just the current model object
> > setConvertedInput(getModelObject();
> > }
> >
> > @Override
> > public void validate() {
> > // validate nested convertedInput which is *not* yet written
> >
> > if (nestedFormComponent.getConvertedInput() ...) {
> > error(...);
> > }
> > }
> >
> > Regards
> > Sven
> >
> >
> > On 12.02.2016 18:17, Sven Meier wrote:
> >> 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 <sv...@meiers.net>
> >>> 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
> >>>>>
>
> --
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Joachim Schrod, Roedermark, Germany
> Email: jschrod@acm.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Question / Modular FormComponents / FormComponentPanels /
AbstractFormValidator and problems with model updates
Posted by Joachim Schrod <js...@acm.org>.
FWIW, for FormComponentPanels I often have an empty implementation
of updateModel() and either have a wrapper method to add validators
for those (abstract) sub-component, or redefine convertInput() to
construct a proper object from
nestedFormComponent.getConvertedInput() to make validators work on
them.
Works most of the time like a charm; except those 0.001% where I
really need to have (a) a proper conversion/validation on the
FormComponentPanel level and (b) full support of AJAX
onchange-updates for the sub-components. Then it get's hairy... :-)
Cheers,
Joachim
On 02/12/16 18:29, Sven Meier wrote:
> Hi again,
>
> now I see what you meant:
>
> Yes, the converted values haven't been written yet.
> I was writing my example off the top of my head :). Validators
> won't help here, you'll have to do validation by hand instead:
>
> PersonPanel extends FormComponentPanel {
> @Override
> protected void convertInput() {
> // converted input is just the current model object
> setConvertedInput(getModelObject();
> }
>
> @Override
> public void validate() {
> // validate nested convertedInput which is *not* yet written
>
> if (nestedFormComponent.getConvertedInput() ...) {
> error(...);
> }
> }
>
> Regards
> Sven
>
>
> On 12.02.2016 18:17, Sven Meier wrote:
>> 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 <sv...@meiers.net>
>>> 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
>>>>>
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Joachim Schrod, Roedermark, Germany
Email: jschrod@acm.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Question / Modular FormComponents / FormComponentPanels /
AbstractFormValidator and problems with model updates
Posted by Sven Meier <sv...@meiers.net>.
Hi Patrick,
sorry for the confusion.
>Does this objection have any consequences for my implementation?
Wicket validates all values *before* they are written into the models.
So validators always validate the converted input only.
You have the following options:
- IValidator, validates the converted input of a single field
- IFormValidator, validates the converted input of multiple fields (but
has to be attached to the form)
- FormComponentPanel, same as IFormValidator - pro: does not need to be
added to form, cons: have to override convertInput() and/or updateModel()
- validate your domain objects after the models have been updated, e.g.
from onClick().
Perhaps you create a quickstart, so we can make sure that we're talking
about the same option.
Regards
Sven
On 15.02.2016 12:35, Patrick Davids wrote:
> Hi Sven,
>
> > Yes, the converted values haven't been written yet.
>
> Does this objection have any consequences for my implementation?
> For me, it semms it is working now... so I think, there is no need to
> me to additionally override
>
> > @Override
> > public void validate() {
> > // validate nested convertedInput which is *not* yet written
> >
> > if (nestedFormComponent.getConvertedInput() ...) {
> > error(...);
> > }
> > }
>
> Should I pay any special attention for an unusual behavior?
> Should I test a special case?
> Whats the risk, leaving my impl. as it is?
> Or am I quite save?
>
> kind regards
> Patrick
>
> Am 12.02.2016 um 18:29 schrieb Sven Meier:
>> Hi again,
>>
>> now I see what you meant:
>>
>> Yes, the converted values haven't been written yet.
>> I was writing my example off the top of my head :). Validators won't
>> help here, you'll have to do validation by hand instead:
>>
>> PersonPanel extends FormComponentPanel {
>> @Override
>> protected void convertInput() {
>> // converted input is just the current model object
>> setConvertedInput(getModelObject();
>> }
>>
>> @Override
>> public void validate() {
>> // validate nested convertedInput which is *not* yet written
>>
>> if (nestedFormComponent.getConvertedInput() ...) {
>> error(...);
>> }
>> }
>>
>> Regards
>> Sven
>>
>>
>> On 12.02.2016 18:17, Sven Meier wrote:
>>> 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 <sv...@meiers.net> 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: users-unsubscribe@wicket.apache.org
>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>
>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>
>>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Question / Modular FormComponents / FormComponentPanels /
AbstractFormValidator and problems with model updates
Posted by Patrick Davids <pa...@nubologic.com>.
Hi Sven,
> Yes, the converted values haven't been written yet.
Does this objection have any consequences for my implementation?
For me, it semms it is working now... so I think, there is no need to me
to additionally override
> @Override
> public void validate() {
> // validate nested convertedInput which is *not* yet written
>
> if (nestedFormComponent.getConvertedInput() ...) {
> error(...);
> }
> }
Should I pay any special attention for an unusual behavior?
Should I test a special case?
Whats the risk, leaving my impl. as it is?
Or am I quite save?
kind regards
Patrick
Am 12.02.2016 um 18:29 schrieb Sven Meier:
> Hi again,
>
> now I see what you meant:
>
> Yes, the converted values haven't been written yet.
> I was writing my example off the top of my head :). Validators won't
> help here, you'll have to do validation by hand instead:
>
> PersonPanel extends FormComponentPanel {
> @Override
> protected void convertInput() {
> // converted input is just the current model object
> setConvertedInput(getModelObject();
> }
>
> @Override
> public void validate() {
> // validate nested convertedInput which is *not* yet written
>
> if (nestedFormComponent.getConvertedInput() ...) {
> error(...);
> }
> }
>
> Regards
> Sven
>
>
> On 12.02.2016 18:17, Sven Meier wrote:
>> 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 <sv...@meiers.net> 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: users-unsubscribe@wicket.apache.org
>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Question / Modular FormComponents / FormComponentPanels /
AbstractFormValidator and problems with model updates
Posted by Sven Meier <sv...@meiers.net>.
Hi again,
now I see what you meant:
Yes, the converted values haven't been written yet.
I was writing my example off the top of my head :). Validators won't
help here, you'll have to do validation by hand instead:
PersonPanel extends FormComponentPanel {
@Override
protected void convertInput() {
// converted input is just the current model object
setConvertedInput(getModelObject();
}
@Override
public void validate() {
// validate nested convertedInput which is *not* yet written
if (nestedFormComponent.getConvertedInput() ...) {
error(...);
}
}
Regards
Sven
On 12.02.2016 18:17, Sven Meier wrote:
> 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 <sv...@meiers.net> 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: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Question / Modular FormComponents / FormComponentPanels /
AbstractFormValidator and problems with model updates
Posted by Sven Meier <sv...@meiers.net>.
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 <sv...@meiers.net> 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: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Question / Modular FormComponents / FormComponentPanels /
AbstractFormValidator and problems with model updates
Posted by Martin Grigorov <mg...@apache.org>.
Hi Sven,
On Fri, Feb 12, 2016 at 12:08 PM, Sven Meier <sv...@meiers.net> 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: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
SOLVED / Re: Question / Modular FormComponents / FormComponentPanels
/ AbstractFormValidator and problems with model updates
Posted by Patrick Davids <pa...@nubologic.com>.
Hi Sven,
thanx for your code-snippet.
Sometimes it is so easy...
Works perfect!
kind regards
Patrick
Am 12.02.2016 um 12:08 schrieb Sven Meier:
> 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();
> }
> }
>
> 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: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Question / Modular FormComponents / FormComponentPanels /
AbstractFormValidator and problems with model updates
Posted by Sven Meier <sv...@meiers.net>.
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();
}
}
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: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org