Re: Understanding phases and UIInput inside of UIData

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

Moving to the dev list.....

Ok.  Here's the problem.  The row state of the UIData is being cleared
when it shouldn't be.

According to the JSF 1.1 RI docs for UIData.encodeBegin, "ensure that
any saved per-row state for our child input components is discarded
unless it is needed to rerender the current page with errors."

That is why setting an error message is making things work.   The docs
should really say something along the lines of "with errors or
unvalidated data".

    public void encodeBegin(FacesContext context) throws IOException
    {
        _initialDescendantComponentState = null;
        if (_isValidChilds && !hasErrorMessages(context))
        {
            //Refresh DataModel for rendering:
            _dataModelMap.clear();
            if (!isPreserveRowStates())
            {
            	_rowStates.clear();
            }
        }
        super.encodeBegin(context);
    }


It seems to me that _isValidChilds should be false by default and only
set to true if the UIData makes it through all of the phases (isn't
short-circuited by a immediate UICommand).   Right now, valid is
assumed to be the default unless a short-circuit is detected for its
own children.   But this doesn't help if it never processes its
children in the first place due to short-circuiting.  Instead, it
should assume failure unless it explicitly detects success.

One workaround might be setting preserveRowStates=true to save the
state, but you really want to have this happen when a command is being
processed in immediate mode, not all the time.

The check for an actual error message is probably a bad idea as
messages on the page have no direct correspondance to whether the
UIInputs in the table are valid.

I hope all of this made sense, but I'm under the influence of
medication right now.  :-)


On 7/8/06, Mike Kienenberger <mk...@gmail.com> wrote:
> Andrew,
>
> I'm hitting the same problem.   I spent half of Friday trying to track
> it down, but I haven't solved it yet.
>
> So far, I've determined that it affects all UIData components
> (h:dataTable, t:dataTable, and t:dataList).
>
> I've also figured out that it has something to do with incorrectly
> restoring the row state for EditableValueHolders in the UIData during
> renderResponse.   The UIData should render the submitted values, but
> those submitted values are wrong.
>
> During applyValues, the submitted values for the UIInputs are
> correctly set and restored, but during renderResponse, the submitted
> values for the UIInputs have mysteriously changed to null.    I'm
> still trying to figure out why the restored table state isn't the same
> in all phases.
>
>
> On 6/30/06, Andrew Robinson <an...@gmail.com> wrote:
> > I had thought I had my problem of phases with UIData figured out, but I am
> > still having issues.
> > I have a data table with input controls in it (inputText for example).
> > Sometimes I lose data in these controls. Here are the use cases and the
> > associated issue:
> >
> > If action immediate set to true, I lose all my data in the data tables
> > If immediate is false my action never fires if a validation error occurs
> > (this is not what I want in this use case, I want my action to ALWAYS fire)
> > If I change the phase ID of the action to the validations phase, and there
> > are validation errors, everything works
> > If I chagne the phase ID of the action to the validations phase and there
> > are no validation errors, I lose my data in the table What I am trying to
> > figure out is the difference between #3 and #4.
> >
> > So, I have changed my action to execute during the processing of
> > validations. This allows me to run my code regardless of validation errors.
> > The side effect is if there are no validation errors, I still lose my data.
> >
> > Why would all my submitted values re-render in the data table when there are
> > validation errors, but not when there are not (I am skipping update model,
> > so in either case it never fires)?
> >
> > I can't see any difference in the code except that with validation errors
> > there is at least one UI component marked as not being valid, but that
> > doesn't seem like it should cause a behavior change with all components on
> > the whole page. If it does how does that work (I couldn't see any such
> > behavior in the code)?
> >
> > I really need to get this sorted out, so if someone could shed some light on
> > how UIData manages to have its child components render submitted values or
> > not I'd really appreciate it.
> >
> > Thanks,
> > Andrew
> >
> >
>