subform and model changes

[Mario Ivankovits <ma...@ops.co.at>]

Hi!

It looks like model changes are not reflected in subforms not subject of
the current request.

So if you have stuff like:

<h:form>
    <h:commandInput .... />
    <h:commandButton id="btn1" .... />

    <s:subForm>
        <h:selectOneMenu .... />
        <h:commandButton id="btn2" .... />
    </s:subForm>
</h:form>

Now if you select one of the elements of the selectOneMenu and press
btn2 everything is fine.
If you enter something in the commandInput and press btn1 which will
change the data the selectOneMenu relies on this works too, but if you
change the value of the selectOneMenu (which is the one which will be
selected then) this do not work as during the render phase the
selectOneMenu component will use its submittedValue instead of the model
value.
As far as I can see this happens as the processValidators phase is
skipped for the subform and thus the submitted value will not be reset.

What do you think if we, instead of just skipping the processValidators
phase, iterate through the components and set their submittedValue to
null so they will get their value from the model again.


Ciao,
Mario

Re: subform and model changes

[Mike Kienenberger <mk...@gmail.com>]

That's probably good enough.   Keeps the "preserve" theme we've used
up to this point and accurately states what's preserved.

On 5/25/07, Mario Ivankovits <ma...@ops.co.at> wrote:
> Hi!
> > How about "keepSubmittedValues" which is a bit more specific than
> > keepInput?
> >
> > However, it doesn't matter too much what we call it.
> >
> > t:dataTable has something called "preserveRowStates" which has a
> > similar purpose, but I can't see how we can use the same name (nor am
> > I sure that preserveRowStates is the best name for the one on
> > t:dataTable).
> preserveSubmittedValues ?
>
>
> Ciao,
> Mario
>
>

Re: subform and model changes

[Mario Ivankovits <ma...@ops.co.at>]

Hi!
> How about "keepSubmittedValues" which is a bit more specific than
> keepInput?
>
> However, it doesn't matter too much what we call it.
>
> t:dataTable has something called "preserveRowStates" which has a
> similar purpose, but I can't see how we can use the same name (nor am
> I sure that preserveRowStates is the best name for the one on
> t:dataTable).
preserveSubmittedValues ?


Ciao,
Mario

Re: subform and model changes

[Mike Kienenberger <mk...@gmail.com>]

How about "keepSubmittedValues" which is a bit more specific than keepInput?

However, it doesn't matter too much what we call it.

t:dataTable has something called "preserveRowStates" which has a
similar purpose, but I can't see how we can use the same name (nor am
I sure that preserveRowStates is the best name for the one on
t:dataTable).



On 5/24/07, Mario Ivankovits <ma...@ops.co.at> wrote:
> Hi !
> > One of my primary use cases is to do something like
> >
> > <set of input field rows>
> > <add-new-row button inside of a subForm>
> This means you allow the user to add some rows and validate the input at
> a later "save" point at once?
>
> However, you won :-)
>
> So I'll try to develop the attribute with a default value to keep the
> current behavior.
>
> Now for a good attribute name (with the value to keep current behavior):
> refetchFromModel=false
> modelRestore=false
> restoreValues=false
> keepInput=true
> ...
>
> I'd opt for "keepInput" which means the subForm will keep the input (by
> default) or in case of "keepInput=false" it will refetch the data from
> the model.
>
>
> Ciao,
> Mario
>
>

Re: subform and model changes

[Mario Ivankovits <ma...@ops.co.at>]

Hi !
> One of my primary use cases is to do something like
>
> <set of input field rows>
> <add-new-row button inside of a subForm>
This means you allow the user to add some rows and validate the input at
a later "save" point at once?

However, you won :-)

So I'll try to develop the attribute with a default value to keep the
current behavior.

Now for a good attribute name (with the value to keep current behavior):
refetchFromModel=false
modelRestore=false
restoreValues=false
keepInput=true
...

I'd opt for "keepInput" which means the subForm will keep the input (by
default) or in case of "keepInput=false" it will refetch the data from
the model.


Ciao,
Mario

Re: subform and model changes

[Mike Kienenberger <mk...@gmail.com>]

No, the main goal of subform was to allow you to submit and validate
part of a page without affecting the rest of the page.

Perhaps for your own use cases, you've primarily used it to do partial
page refreshing, but that's not how I've used it.   I would disagree
that this is the majority use case since no one else has posted an
issue with the current behavior up to this point :-)

One of my primary use cases is to do something like

<set of input field rows>
<add-new-row button inside of a subForm>

Losing the unvalidated input of the fields outside of the subform
would be unacceptable.

While it's true that s:subForm is still in the sandbox, it's only
because of lack of time that it's not been promoted yet.   We took a
straw poll a few months back and no one saw any reason why it couldn't
be promoted at that point.

It seems like a reasonable suggestion to allow the behavior you've
suggested, but there's no reason to assume that your new behavior
should be the default behavior, especially since it will change the
behavior of existing applications.

On 5/24/07, Mario Ivankovits <ma...@ops.co.at> wrote:
> Hi Mike!
> > If you want to change the submitted values to the backing bean, then
> > you need to do so in code just as if you wanted to do it for a regular
> > form.
> >
> > http://wiki.apache.org/myfaces/ClearInputComponents
> Yep, I am aware of this, but I really hate to use component bindings.
> This is alway a "last resort" for me.
>
> > That said, I'd not be opposed to adding an attribute to a subform to
> > configure it to refetch from the model so long as that was not the
> > default behavior.
> Hmmm .... not issuing the validation and not updating the model to allow
> to submit another form was the main goal of subForm, no?
> If we say subForm was introduced to avoid the use of multiple h:forms on
> the page, then it should refetch from the model by default.
>
> I'd like to add a parameter ... maybe called "refetchFromModel" ... with
> a default value of "true". I am sure this is the major use case,
> especially if you keep in mind that e.g. you can change the options of a
> select*Listbox but not its value (yet).
> It's a sandbox component, I think we can argue the change.
>
> Any objections?
>
> Ciao,
> Mario
>
>

Re: subform and model changes

[Mario Ivankovits <ma...@ops.co.at>]

Hi Mike!
> If you want to change the submitted values to the backing bean, then
> you need to do so in code just as if you wanted to do it for a regular
> form.
>
> http://wiki.apache.org/myfaces/ClearInputComponents
Yep, I am aware of this, but I really hate to use component bindings.
This is alway a "last resort" for me.

> That said, I'd not be opposed to adding an attribute to a subform to
> configure it to refetch from the model so long as that was not the
> default behavior.
Hmmm .... not issuing the validation and not updating the model to allow
to submit another form was the main goal of subForm, no?
If we say subForm was introduced to avoid the use of multiple h:forms on
the page, then it should refetch from the model by default.

I'd like to add a parameter ... maybe called "refetchFromModel" ... with
a default value of "true". I am sure this is the major use case,
especially if you keep in mind that e.g. you can change the options of a
select*Listbox but not its value (yet).
It's a sandbox component, I think we can argue the change.

Any objections?

Ciao,
Mario

Re: subform and model changes

[Mike Kienenberger <mk...@gmail.com>]

This is how subforms are supposed to work -- changes and submits in
one subform should not impact the current submitted values of the
others.

If you want to change the submitted values to the backing bean, then
you need to do so in code just as if you wanted to do it for a regular
form.

http://wiki.apache.org/myfaces/ClearInputComponents

That said, I'd not be opposed to adding an attribute to a subform to
configure it to refetch from the model so long as that was not the
default behavior.

On 5/24/07, Mario Ivankovits <ma...@ops.co.at> wrote:
> Hi!
>
> It looks like model changes are not reflected in subforms not subject of
> the current request.
>
> So if you have stuff like:
>
> <h:form>
>     <h:commandInput .... />
>     <h:commandButton id="btn1" .... />
>
>     <s:subForm>
>         <h:selectOneMenu .... />
>         <h:commandButton id="btn2" .... />
>     </s:subForm>
> </h:form>
>
> Now if you select one of the elements of the selectOneMenu and press
> btn2 everything is fine.
> If you enter something in the commandInput and press btn1 which will
> change the data the selectOneMenu relies on this works too, but if you
> change the value of the selectOneMenu (which is the one which will be
> selected then) this do not work as during the render phase the
> selectOneMenu component will use its submittedValue instead of the model
> value.
> As far as I can see this happens as the processValidators phase is
> skipped for the subform and thus the submitted value will not be reset.
>
> What do you think if we, instead of just skipping the processValidators
> phase, iterate through the components and set their submittedValue to
> null so they will get their value from the model again.
>
>
> Ciao,
> Mario
>
>