myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Vieujot <svieu...@apache.org>
Subject Re: [Fwd: Re: AliasBean]
Date Sat, 19 Mar 2005 04:52:59 GMT
Hello Martin,

I didn't had enough time to explore this issue, but I'm convinced the
current code isn't right.

Indeed, here is the refresh method from HtmlDataTable :


    protected void refresh(FacesContext context)
    {
        if (log.isDebugEnabled()) log.debug("Refresh for HtmlDataTable " + getClientId(context)
+ " was called");
        
        if (_firstTimeRendered || isAllChildrenAndFacetsValid())
        {
            // No invalid children
            // --> clear data model
            _dataModel = null;
            if (_dataModelMap != null) _dataModelMap.clear();
            _isDataModelRestored = false;

            _saveDescendantStates = false; // no need to save children states
        }
        else
        {
            _saveDescendantStates = true; // save children states (valid flag, submittedValues,
etc.)
        }
    }

In the above code, we don't save the descendant states if all children
and facets are valid.
But in the case of a dataTable inside a tab pane, if you changed some
components in the dataTable, and then switch tab, the children and
facets are valid, but they still have submitted values that haven't been
set in the back-end components.
This is normal and should be so, but not saving them means that you're
loosing them.
This is what happened in the webapp example, tabbed panel component page
if you go to tab 3 check some check boxes in the check boxes list and/or
enter text in the texts boxes next to them. If you then select tab2, and
then select again tab3, all your values are gone.

My previous fix wasn't good enough, but I still think the argumentation
and the example holds.
Maybe some other part of the code has another bug too.

Anyway, I suggest we keep the current code until we have released the
1.0.9 version, and then that we work on really fixing this issue.
Do you agree with that ?

Thanks,

Sylvain.


On Fri, 2005-03-04 at 11:33 -0400, Sylvain Vieujot wrote:

> Ok, I got it now.
> 
> I'll dig into the example to find out why.
> 
> Thanks.
> 
> On Fri, 2005-03-04 at 15:35 +0100, Martin Marinschek wrote: 
> 
> > You understood me wrongly, you don't need to brutalize the example.
> > 
> > Step by Step:
> > 
> > - put in your changes again.
> > 
> > - go to "master/detail"
> > 
> > - click on "edit all countries" (this is a subview, you go away from
> > the master/details example)
> > 
> > - click on "add a country" - nothing happens...
> > - click on "delete a country" - nothing happens as well..
> > 
> > regards,
> > 
> > Martin
> > 
> > 
> > 
> > 
> > On Fri, 04 Mar 2005 08:20:24 -0400, Sylvain Vieujot <svieujot@apache.org>
wrote:
> > >  I just checked again, and tried to "brutalize" the Master/Details example,
> > > but I can't find any sporadic behavior.
> > >  Could you give me a step by step example ?
> > >  
> > >  Also, the code you removed was just me disabling an optimization that in
> > > some cases forced the state to not be saved.
> > >  The optimization make some sens, but it was just a little to aggressive,
> > > which caused the state to be lost once the table is in a tabbed panel (for
> > > example).
> > >  
> > >  So, I don't see how it could affect the Master/Details example. I'm not
> > > pretending it's not, I just don't understand how it could, and I don't see
> > > that happening in my tests.
> > >  
> > >  What's your opinion about the tabbed panel that should behave as if it was
> > > done all on the client side ?
> > >  
> > >  Thanks,
> > >  
> > >  Sylvain.
> > > 
> > >  
> > >  On Fri, 2005-03-04 at 09:36 +0100, Martin Marinschek wrote: 
> > >  The problem is that the "add country" and the "delete country" link do work
> > > only sporadic any more... regards, Martin On Fri, 04 Mar 2005 00:24:46
> > > -0400, Sylvain Vieujot <svieujot@apache.org> wrote: > Martin, >
> I just
> > > checked the "old" version - that is before your last commits of > today,
and
> > > I don't find bugs in the Master/Detail example. > What bug do you have ?
> >
> > > Thanks, > > Sylvain. > > > -------- Forwarded Message --------
> From:
> > > Sylvain Vieujot <svieujot@apache.org> > Reply-To: MyFaces Development
> > > <myfaces-dev@incubator.apache.org> > To: martin@marinschek.com >
Cc: MyFaces
> > > Development <myfaces-dev@incubator.apache.org> > Subject: Re: AliasBean
>
> > > Date: Fri, 04 Mar 2005 00:16:05 -0400 > Hello Martin, > > My understanding
> > > is that values should indeed be written to the backing > bean, but only
> > > after a command/action. > If the submit is just the result of an event that
> > > is meant for rendering > purposes only, then it shouldn't be written to
the
> > > backing bean. > > Let's take an example with the tabs : > Let's take
a form
> > > with 2 tabs, and a save button at the bottom (that is not > in the tabs).
> > > Switching tab should not save the data (write the values to > the backing
> > > bean). > The tab should work as if it was written using Dynamic HTML (which
> > > by the > way would be a nice extension for this component). > > So,
the
> > > tabbed panel should not validate the data. It should just refresh > the
> > > display. > > Best regards, > > Sylvain. > > On Fri, 2005-03-04
at 02:19
> > > +0100, Martin Marinschek wrote: > maybe this would be the idea: you would
> > > not let the tabbed panel validate > through in case the tab was changed?
> > > Might that work? regards, Martin On > Fri, 4 Mar 2005 02:16:21 +0100, Martin
> > > Marinschek > <martin.marinschek@gmail.com> wrote: > another one:
> >
> > > Sylvain, you changed > the HtmlDataTable - this might have resolved a >
bug
> > > for you, but opened up > several others for me. Please do not change >
this
> > > part of the code without > checking if all functionality under >
> > > Master/Detail example is still > working, especially the "Edit all >
> > > countries" Link and everything under it. > > > Apart from that and
once
> > > more: I strongly believe that JSF is supposed > > to work the way the
code
> > > was orginally meant to be, if you submit a > value, > and it is valid,
it
> > > will be written through to the backing > bean! This is > what ought to
> > > happen. And if it is not valid, it should > not be written > back, and
this
> > > is where things like the > preserveDataModel kick in, they > store the
> > > data-model in the meantime, > and next time when the validation > runs
> > > through the data can be stored > to the backing bean. > > Do you have
>
> > > another opinion? > > regards, > > Martin > > On Fri, 4 Mar
2005 01:51:49 >
> > > +0100, Martin Marinschek > <martin.marinschek@gmail.com> wrote: >
> forget >
> > > that... > > > > my fault! > > > > regards, > >
> > Martin > > > > > > On >
> > > Fri, 4 Mar 2005 01:50:25 +0100, Martin Marinschek > > >
> > > <martin.marinschek@gmail.com> wrote: > > > Hi Sylvain, >
> > > > > something
> > > > doesn't quite work in the alias bean (example) in the > > > current
>
> > > configuration. Can you check that? > > > > > > regards, >
> > > > > Martin >
> > > > > > > > >

Mime
View raw message