You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Alessandro Polverini <al...@nibbles.it> on 2005/01/05 23:02:04 UTC
Wrong behaviour of x:panelTabbedPane
Hello,
I'm reposting this to -dev because I got no feedback at all on -user.
I just want someone to confirm the problem so that I can open a bug report
on Jira if it's correct to do so.
I'm experimenting a little with tab panels but I've some problems and
I can't understand if I'm doing something wrong or the implementation
of tab panels is buggy.
The only values saved between tab switches are the ones inside
inputTexts, the other components (in this example a checkbox and a
date).
To test the wrong behaviour is simple: check the checkBox and select a
date, then switch to tab2, and then on tab1 again: everything is reset
to default.
Also, it can be noted the bug of the popup calendar: the popup opened is
wrong if the year field is empty, but I've opened a bug report for that
at http://issues.apache.org/jira/browse/MYFACES-73 .
This is the JSP code I'm using:
<%@page contentType="text/html"%>
<%@page pageEncoding="UTF-8"%>
<%@ taglib uri="http://java.sun.com/jsf/html" prefix="h" %>
<%@ taglib uri="http://java.sun.com/jsf/core" prefix="f" %>
<%@ taglib uri="http://myfaces.apache.org/extensions" prefix="x"%>
<html>
<body>
<f:view>
<x:panelTabbedPane bgcolor="#FFFFCC" >
<x:panelTab id="tab1" label="Tab1" >
<h:outputLabel for="bool1" value="Bool1"/>
<h:selectBooleanCheckbox id="bool1" value="#{myMap.bool1}" />
<h:outputText value="Date1"/>
<x:inputDate id="date1" value="#{myMap.date1}"
popupCalendar="true"/>
<h:message for="date1"/>
</x:panelTab>
<x:panelTab id="tab2" label="Tab2" >
<h:outputText value="Date2"/>
<x:inputDate id="date2" value="#{myMap.date2}"
popupCalendar="true"/>
<h:message for="date2"/>
</x:panelTab>
</x:panelTabbedPane>
</f:view>
</body>
</html>
and this is the managed bean declaration:
<managed-bean>
<managed-bean-name>myMap</managed-bean-name>
<managed-bean-class>java.utils.HashMap</managed-bean-class>
<managed-bean-scope>session</managed-bean-scope>
</managed-bean>
Thanks for any help,
Alex
Re: Wrong behaviour of x:panelTabbedPane
Posted by Alessandro Polverini <al...@nibbles.it>.
On Mon, 2005-01-24 at 12:36 -0400, Sylvain Vieujot wrote:
> Hello Alex,
>
> Could you check again, as Martin has just posted a fix to the tabbed
> panel that might have solved your problem.
Hello Sylvain, and thanks for your reply.
I compiled from CVS (when the switch to subversion? ;) ), I tested again
on the updated example tabbedPane.jsp I provided as attachment of
MYFACES-82, and I verified that:
- date fields and checkboxes are now mantained correctly
- radio buttons status are not preserved
- multiple choices are also handled wrong since every choice is selected
- calendar component still has the "NaN" bug (see MYFACES-73)
I still think that an updated tabbedPane.jsp similar to the one provided
by me should be put on the distribution, so that it's easier to check
for regressions (or bad behaviours).
Thanks,
Alex
Re: Wrong behaviour of x:panelTabbedPane
Posted by Sylvain Vieujot <sv...@freelance.com>.
Hello Alex,
Could you check again, as Martin has just posted a fix to the tabbed
panel that might have solved your problem.
Sylvain.
On Fri, 2005-01-07 at 22:39 +0100, Alessandro Polverini wrote:
> On Thu, 2005-01-06 at 21:55 -0400, Sylvain Vieujot wrote:
> > Hello Alex,
> >
> > I think I fixed just the bug for selectOneRadio.
>
> I checked on my simple example and it seems still broken :(
>
> > But we still have an issues for UISelectItems.
> > If someone could look at line 140 of the HtmlCheckBoxRendererBase, and
> > line 463 of the RendererUtils, it would be great, as I think they too
> > are using the component's value, instead of checking for a submitted
> > value first.
> > I can't work on this right now as I'll be away from my computer for a
> > week, and I don't want to take the risk of breaking it before leaving.
>
> I'm sorry I'm really far from able to be useful in this case... I hope
> someone other can help.
>
> Thanks,
> Alex
>
Re: Wrong behaviour of x:panelTabbedPane
Posted by Alessandro Polverini <al...@nibbles.it>.
On Thu, 2005-01-06 at 21:55 -0400, Sylvain Vieujot wrote:
> Hello Alex,
>
> I think I fixed just the bug for selectOneRadio.
I checked on my simple example and it seems still broken :(
> But we still have an issues for UISelectItems.
> If someone could look at line 140 of the HtmlCheckBoxRendererBase, and
> line 463 of the RendererUtils, it would be great, as I think they too
> are using the component's value, instead of checking for a submitted
> value first.
> I can't work on this right now as I'll be away from my computer for a
> week, and I don't want to take the risk of breaking it before leaving.
I'm sorry I'm really far from able to be useful in this case... I hope
someone other can help.
Thanks,
Alex
Re: Wrong behaviour of x:panelTabbedPane
Posted by Sylvain Vieujot <sv...@apache.org>.
Hello Alex,
I think I fixed just the bug for selectOneRadio.
But we still have an issues for UISelectItems.
If someone could look at line 140 of the HtmlCheckBoxRendererBase, and
line 463 of the RendererUtils, it would be great, as I think they too
are using the component's value, instead of checking for a submitted
value first.
I can't work on this right now as I'll be away from my computer for a
week, and I don't want to take the risk of breaking it before leaving.
An easy way to test test the problem is the same as for any component :
Put the component in an tab panel, with at least 2 tabs. Change the
component value, and then switch to another tab.
This should set the component's submitted value, but not change the
backing bean value.
When you switch back to initial tab, you should have the changed value.
If the user changes have been lost, then the component's renderer has a
bug. It always renders the backing bean value instead of looking first
for a submitted value.
By the way, if we could implement this test with cactus for every
component it would be great, as it's a really tempting error when you
write a renderer, and I think more basic components still have this bug.
Best regards,
Sylvain.
On Thu, 2005-01-06 at 22:45 +0100, Alessandro Polverini wrote:
> Hello Sylvain, and thanks very much for your reply.
>
> On Wed, 2005-01-05 at 19:07 -0400, Sylvain Vieujot wrote:
> > I think this is the same as the bug we had for several components
> > (using the uiComponent.getValue() instead of the
> > uiComponent.getSubmittedValue() ).
> >
> > As for the x:inputDate, it should be solved in version that should be
> > released in a few days.
>
> Ok, I'll wait the new release and test again.
>
> > For the checkbox, I just committed a fix that I hope will work.
>
> I compiled from cvs and the checkbox works fine now! Thanks!
>
> > Looking at the HtmlCheckBoxRendererBase, I think we have a similar
> > issue for renderCheckboxList (HtmlCheckBoxRendererBase, line 139).
> > If somebody can check this please.
>
> Please explain me which test I have to do and I'll be glad to do them.
> In the meantime I can say that also the tag x:selectOneRadio has the
> problem to forget current values as checkbox had.
>
> Thanks,
> Alex
>
>
Re: Wrong behaviour of x:panelTabbedPane
Posted by Alessandro Polverini <al...@nibbles.it>.
Hello Sylvain, and thanks very much for your reply.
On Wed, 2005-01-05 at 19:07 -0400, Sylvain Vieujot wrote:
> I think this is the same as the bug we had for several components
> (using the uiComponent.getValue() instead of the
> uiComponent.getSubmittedValue() ).
>
> As for the x:inputDate, it should be solved in version that should be
> released in a few days.
Ok, I'll wait the new release and test again.
> For the checkbox, I just committed a fix that I hope will work.
I compiled from cvs and the checkbox works fine now! Thanks!
> Looking at the HtmlCheckBoxRendererBase, I think we have a similar
> issue for renderCheckboxList (HtmlCheckBoxRendererBase, line 139).
> If somebody can check this please.
Please explain me which test I have to do and I'll be glad to do them.
In the meantime I can say that also the tag x:selectOneRadio has the
problem to forget current values as checkbox had.
Thanks,
Alex
Re: Wrong behaviour of x:panelTabbedPane
Posted by Sylvain Vieujot <sv...@apache.org>.
I think this is the same as the bug we had for several components (using
the uiComponent.getValue() instead of the uiComponent.getSubmittedValue
() ).
As for the x:inputDate, it should be solved in version that should be
released in a few days.
For the checkbox, I just committed a fix that I hope will work.
Looking at the HtmlCheckBoxRendererBase, I think we have a similar issue
for renderCheckboxList (HtmlCheckBoxRendererBase, line 139).
If somebody can check this please.
Thanks,
Sylvain.
P.S. I attached bellow a previous email I wrote with the explanation of
similar bugs.
On Wed, 2005-01-05 at 23:02 +0100, Alessandro Polverini wrote:
> Hello,
> I'm reposting this to -dev because I got no feedback at all on -user.
> I just want someone to confirm the problem so that I can open a bug report
> on Jira if it's correct to do so.
>
> I'm experimenting a little with tab panels but I've some problems and
> I can't understand if I'm doing something wrong or the implementation
> of tab panels is buggy.
> The only values saved between tab switches are the ones inside
> inputTexts, the other components (in this example a checkbox and a
> date).
>
> To test the wrong behaviour is simple: check the checkBox and select a
> date, then switch to tab2, and then on tab1 again: everything is reset
> to default.
>
> Also, it can be noted the bug of the popup calendar: the popup opened is
> wrong if the year field is empty, but I've opened a bug report for that
> at http://issues.apache.org/jira/browse/MYFACES-73 .
>
> This is the JSP code I'm using:
>
> <%@page contentType="text/html"%>
> <%@page pageEncoding="UTF-8"%>
> <%@ taglib uri="http://java.sun.com/jsf/html" prefix="h" %>
> <%@ taglib uri="http://java.sun.com/jsf/core" prefix="f" %>
> <%@ taglib uri="http://myfaces.apache.org/extensions" prefix="x"%>
> <html>
> <body>
>
> <f:view>
> <x:panelTabbedPane bgcolor="#FFFFCC" >
>
> <x:panelTab id="tab1" label="Tab1" >
> <h:outputLabel for="bool1" value="Bool1"/>
> <h:selectBooleanCheckbox id="bool1" value="#{myMap.bool1}" />
> <h:outputText value="Date1"/>
> <x:inputDate id="date1" value="#{myMap.date1}"
> popupCalendar="true"/>
> <h:message for="date1"/>
> </x:panelTab>
>
> <x:panelTab id="tab2" label="Tab2" >
> <h:outputText value="Date2"/>
> <x:inputDate id="date2" value="#{myMap.date2}"
> popupCalendar="true"/>
> <h:message for="date2"/>
> </x:panelTab>
>
> </x:panelTabbedPane>
> </f:view>
>
> </body>
> </html>
>
> and this is the managed bean declaration:
> <managed-bean>
> <managed-bean-name>myMap</managed-bean-name>
> <managed-bean-class>java.utils.HashMap</managed-bean-class>
> <managed-bean-scope>session</managed-bean-scope>
> </managed-bean>
>
> Thanks for any help,
> Alex
>
>
-------- Forwarded Message --------
From: Sylvain Vieujot <sv...@apache.org>
To: MyFaces Development <my...@incubator.apache.org>
Subject: Commun error on restoring submitted values
Date: Thu, 09 Dec 2004 01:09:41 -0400
While playing with the htmlEditor component, I found that if a page is
only refreshed (like when you click on a tab of an x:panelTab), then the
submitted value was lost, and replaced with the component's backing bean
value.
The reason, for that is that I was using a code like this in the
renderer :
String textToRender = uiComponent.getValue();
Doing this, the textToRender is always the same until the form is
validated, and the Update Model Values phase is run. And any
intermediary rendering will just reset the data entered by the user.
A better code would be :
String textToRender = uiComponent.getSubmittedValue()!=null ?
uiComponent.getSubmittedValue() : uiComponent.getValue();
For a really correct code, look at the following helper function in :
org.apache.myfaces.renderkit.RendererUtils.getStringValue
I'm sending this email to the mailing list because it is quite easy to
fall for this bug, and I think I've already found 2 places in the
extensions renderers where we have this bug : in the calendar renderer,
and in the date renderer.
I've marked the places in the sources where I think is the bug, but we
might find other occurrences.
Sylvain.