You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Sylvain Vieujot <sv...@apache.org> on 2005/03/04 05:24:46 UTC
[Fwd: Re: AliasBean]
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 <sv...@apache.org>
Reply-To: MyFaces Development <my...@incubator.apache.org>
To: martin@marinschek.com
Cc: MyFaces Development <my...@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
> <ma...@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
> > <ma...@gmail.com> wrote:
> > > forget that...
> > >
> > > my fault!
> > >
> > > regards,
> > >
> > > Martin
> > >
> > >
> > > On Fri, 4 Mar 2005 01:50:25 +0100, Martin Marinschek
> > > <ma...@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
> > > >
> > >
> >
Re: [Fwd: Re: AliasBean]
Posted by Martin Marinschek <ma...@gmail.com>.
For a solution to your tabbed panel problem, we would need to have the
following:
- the submitted value of all the components on all panels need to be
saved, regardless if they are rendered or not.
- a tab change must always set the isValid of the component to false,
and such prevent writing the submitted value to the backing bean.
Implement these two behaviours, and we comply to the spec + have all
the necessary functionality you need!
regards,
Martin
On Fri, 4 Mar 2005 15:35:17 +0100, Martin Marinschek
<ma...@gmail.com> 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 <sv...@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 <sv...@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 <sv...@apache.org> > Reply-To: MyFaces Development
> > <my...@incubator.apache.org> > To: martin@marinschek.com > Cc: MyFaces
> > Development <my...@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 > <ma...@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 > <ma...@gmail.com> wrote: > > forget >
> > that... > > > > my fault! > > > > regards, > > > > Martin > > > > > > On >
> > Fri, 4 Mar 2005 01:50:25 +0100, Martin Marinschek > > >
> > <ma...@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 >
> > > > > > > >
>
AW: [Fwd: Re: AliasBean]
Posted by Martin Marinschek <ma...@marinschek.com>.
Yes to release the code as is right now
And yes to hopefully resolve that issue later. I still believe that we need
a different solution than you are proposing, but we can discuss that later
on.
Regards,
Martin
_____
Von: Sylvain Vieujot [mailto:svieujot@apache.org]
Gesendet: Samstag, 19. März 2005 05:53
An: martin@marinschek.com
Cc: MyFaces Development
Betreff: Re: [Fwd: Re: AliasBean]
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 <sv...@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 <sv...@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 <sv...@apache.org> > Reply-To: MyFaces Development
> <my...@incubator.apache.org> > To: martin@marinschek.com > Cc:
MyFaces
> Development <my...@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 > <ma...@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 > <ma...@gmail.com> wrote: > > forget
>
> that... > > > > my fault! > > > > regards, > > > > Martin > > > > > > On >
> Fri, 4 Mar 2005 01:50:25 +0100, Martin Marinschek > > >
> <ma...@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
>
> > > > > > >
Re: [Fwd: Re: AliasBean]
Posted by Sylvain Vieujot <sv...@apache.org>.
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 <sv...@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 <sv...@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 <sv...@apache.org> > Reply-To: MyFaces Development
> > > <my...@incubator.apache.org> > To: martin@marinschek.com > Cc: MyFaces
> > > Development <my...@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 > <ma...@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 > <ma...@gmail.com> wrote: > > forget >
> > > that... > > > > my fault! > > > > regards, > > > > Martin > > > > > > On >
> > > Fri, 4 Mar 2005 01:50:25 +0100, Martin Marinschek > > >
> > > <ma...@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 >
> > > > > > > > >
Re: [Fwd: Re: AliasBean]
Posted by Sylvain Vieujot <sv...@apache.org>.
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 <sv...@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 <sv...@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 <sv...@apache.org> > Reply-To: MyFaces Development
> > <my...@incubator.apache.org> > To: martin@marinschek.com > Cc: MyFaces
> > Development <my...@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 > <ma...@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 > <ma...@gmail.com> wrote: > > forget >
> > that... > > > > my fault! > > > > regards, > > > > Martin > > > > > > On >
> > Fri, 4 Mar 2005 01:50:25 +0100, Martin Marinschek > > >
> > <ma...@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 >
> > > > > > > >
Re: [Fwd: Re: AliasBean]
Posted by Martin Marinschek <ma...@gmail.com>.
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 <sv...@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 <sv...@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 <sv...@apache.org> > Reply-To: MyFaces Development
> <my...@incubator.apache.org> > To: martin@marinschek.com > Cc: MyFaces
> Development <my...@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 > <ma...@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 > <ma...@gmail.com> wrote: > > forget >
> that... > > > > my fault! > > > > regards, > > > > Martin > > > > > > On >
> Fri, 4 Mar 2005 01:50:25 +0100, Martin Marinschek > > >
> <ma...@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 >
> > > > > > >
Re: [Fwd: Re: AliasBean]
Posted by Sylvain Vieujot <sv...@apache.org>.
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 <sv...@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 <sv...@apache.org>
> > Reply-To: MyFaces Development <my...@incubator.apache.org>
> > To: martin@marinschek.com
> > Cc: MyFaces Development <my...@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
> > <ma...@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 > <ma...@gmail.com> wrote: > > forget
> > that... > > > > my fault! > > > > regards, > > > > Martin > > > > > > On
> > Fri, 4 Mar 2005 01:50:25 +0100, Martin Marinschek > >
> > <ma...@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 >
> > > > > > >
Re: [Fwd: Re: AliasBean]
Posted by Martin Marinschek <ma...@gmail.com>.
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 <sv...@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 <sv...@apache.org>
> Reply-To: MyFaces Development <my...@incubator.apache.org>
> To: martin@marinschek.com
> Cc: MyFaces Development <my...@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
> <ma...@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 > <ma...@gmail.com> wrote: > > forget
> that... > > > > my fault! > > > > regards, > > > > Martin > > > > > > On
> Fri, 4 Mar 2005 01:50:25 +0100, Martin Marinschek > >
> <ma...@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 >
> > > > > >