You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by "Todd Gould (JIRA)" <de...@myfaces.apache.org> on 2007/09/04 21:50:48 UTC
[jira] Created: (TOMAHAWK-1104) does not
completely recover from submitted date/time formatting/validation errors
<t:inputCalendar> does not completely recover from submitted date/time formatting/validation errors
---------------------------------------------------------------------------------------------------
Key: TOMAHAWK-1104
URL: https://issues.apache.org/jira/browse/TOMAHAWK-1104
Project: MyFaces Tomahawk
Issue Type: Bug
Components: Calendar
Affects Versions: 1.1.6
Environment: Windows XP, IE 6, MyFaces 1.1.5, Tomahawk 1.1.6
Reporter: Todd Gould
There appears to be a probelm with the <t:inutCalendar> component recovering from user entry errors. For example, if I am using the following tag in a JSP:
<t:inputCalendar id="SinceAlertTime"
value="#{alertSummaryController.sinceTime}"
popupDateFormat="MM/dd/yyyy HH:mm:ss" helpText="MM/dd/yyyy HH:mm:ss"
title="MM/dd/yyyy HH:mm:ss"
popupSelectDateMessage="Select [date] as date"
renderAsPopup="true" renderPopupButtonAsImage="true">
All works as desired unless the user manually enters an invalid date/time format (for example a typo) in the associated text entry field generated by this component. In this case the scenario is as follows:
1. The user inadvertently enters a bad date/time format into the associated text entry field and subsequently submits the form.
2. The validation error is correctly created and displayed back to the user (validation failed, so Invoke Application phase never performed).
3. The user then corrects their error by either manually entering a valid format in the associated text entry field or by invoking the popup and selecting a date.
4. The user then submits the form and the now corrected date is apparently accepted (i.e. no validation error). However, the previously unvalid value is retained as the backing bean is not set and the resulting display contains the user entered invalid date/time format upon redisplay.
We are using CLIENT stat saving method as our ajax implementation relies upon this. If have not had a chance to see if that matters, but submit it for complete information.
This is a severe problem for us as our user community frequently uses both the popup to select a date and then subsequently manually adjusts the time portion in the text entry field. If they inadvertantly creat and invalid entry in this fashion, they are basically stuck as there the component does not appear to recover upon re-submission of valid date/time values in the associated text entry field - i.e. the error keeps re-appearing upon subsequent submissions.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TOMAHAWK-1104) does not
completely recover from submitted date/time formatting/validation errors
Posted by "Todd Gould (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/TOMAHAWK-1104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Todd Gould updated TOMAHAWK-1104:
---------------------------------
Status: Patch Available (was: Open)
> <t:inputCalendar> does not completely recover from submitted date/time formatting/validation errors
> ---------------------------------------------------------------------------------------------------
>
> Key: TOMAHAWK-1104
> URL: https://issues.apache.org/jira/browse/TOMAHAWK-1104
> Project: MyFaces Tomahawk
> Issue Type: Bug
> Components: Calendar
> Affects Versions: 1.1.6
> Environment: Windows XP, IE 6, MyFaces 1.1.5, Tomahawk 1.1.6
> Reporter: Todd Gould
>
> There appears to be a probelm with the <t:inutCalendar> component recovering from user entry errors. For example, if I am using the following tag in a JSP:
> <t:inputCalendar id="SinceAlertTime"
> value="#{alertSummaryController.sinceTime}"
> popupDateFormat="MM/dd/yyyy HH:mm:ss" helpText="MM/dd/yyyy HH:mm:ss"
> title="MM/dd/yyyy HH:mm:ss"
> popupSelectDateMessage="Select [date] as date"
> renderAsPopup="true" renderPopupButtonAsImage="true">
> All works as desired unless the user manually enters an invalid date/time format (for example a typo) in the associated text entry field generated by this component. In this case the scenario is as follows:
> 1. The user inadvertently enters a bad date/time format into the associated text entry field and subsequently submits the form.
> 2. The validation error is correctly created and displayed back to the user (validation failed, so Invoke Application phase never performed).
> 3. The user then corrects their error by either manually entering a valid format in the associated text entry field or by invoking the popup and selecting a date.
> 4. The user then submits the form and the now corrected date is apparently accepted (i.e. no validation error). However, the previously unvalid value is retained as the backing bean is not set and the resulting display contains the user entered invalid date/time format upon redisplay.
> We are using CLIENT stat saving method as our ajax implementation relies upon this. If have not had a chance to see if that matters, but submit it for complete information.
> This is a severe problem for us as our user community frequently uses both the popup to select a date and then subsequently manually adjusts the time portion in the text entry field. If they inadvertantly creat and invalid entry in this fashion, they are basically stuck as there the component does not appear to recover upon re-submission of valid date/time values in the associated text entry field - i.e. the error keeps re-appearing upon subsequent submissions.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TOMAHAWK-1104) does not
completely recover from submitted date/time formatting/validation errors
Posted by "Todd Gould (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/TOMAHAWK-1104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Todd Gould updated TOMAHAWK-1104:
---------------------------------
Status: Patch Available (was: Open)
> <t:inputCalendar> does not completely recover from submitted date/time formatting/validation errors
> ---------------------------------------------------------------------------------------------------
>
> Key: TOMAHAWK-1104
> URL: https://issues.apache.org/jira/browse/TOMAHAWK-1104
> Project: MyFaces Tomahawk
> Issue Type: Bug
> Components: Calendar
> Affects Versions: 1.1.6
> Environment: Windows XP, IE 6, MyFaces 1.1.5, Tomahawk 1.1.6
> Reporter: Todd Gould
>
> There appears to be a problem with the <t:inutCalendar> component recovering from user entry errors. For example, if I am using the following tag in a JSP:
> <t:inputCalendar id="SinceAlertTime"
> value="#{alertSummaryController.sinceTime}"
> popupDateFormat="MM/dd/yyyy HH:mm:ss" helpText="MM/dd/yyyy HH:mm:ss"
> title="MM/dd/yyyy HH:mm:ss"
> popupSelectDateMessage="Select [date] as date"
> renderAsPopup="true" renderPopupButtonAsImage="true">
> All works as desired unless the user manually enters an invalid date/time format (for example a typo) in the associated text entry field generated by this component. In this case the scenario is as follows:
> 1. The user inadvertently enters a bad date/time format into the associated text entry field and subsequently submits the form.
> 2. The validation error is correctly created and displayed back to the user (validation failed, so Invoke Application phase never performed).
> 3. The user then corrects their error by either manually entering a valid format in the associated text entry field or by invoking the popup and selecting a date.
> 4. The user then submits the form and the now corrected date is apparently accepted (i.e. no validation error). However, the previously invalid value is retained as the backing bean is not set and the resulting text entry field displayed contains the user entered invalid date/time format upon redisplay.
> We are using CLIENT state saving method as our ajax implementation relies upon this. I have not had a chance to see if that matters or not, but submit it for complete information.
> This is a severe problem for us as our user community frequently uses both the popup to select a date and then subsequently manually adjusts the time portion in the text entry field. If they inadvertantly create an invalid entry in this fashion, they are basically stuck as the component does not appear to recover upon re-submission of valid date/time values in the associated text entry field - i.e. the error keeps re-appearing upon subsequent submissions.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TOMAHAWK-1104) does not
completely recover from submitted date/time formatting/validation errors
Posted by "Todd Gould (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/TOMAHAWK-1104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12525146 ]
Todd Gould commented on TOMAHAWK-1104:
--------------------------------------
Some debugging has shown that the restoreState() method in the org.apache.myfaces.custom.calendar.HtmlInputCalendar manifests/creates the problem. This method properly delegates up the super.restoreState() chain wih the retrieved state (in my case from the client state saving method). This utlimately gets to the UIInput class which dutifly restores the 'submittedValue' attribute of the class which contains the erroneously formatted input from preceeding failure(s). As there appears to be nothing within the other workings of this component to to change that 'submittedValue' attribute's value in any other than failure conditions, it becomes explainable while I am seeing the irrecoverability behavior.
I have developed a workaround for this problem. I'm sure it is far less than optimal, but it works for now until those more enlightened than I can have a chance to offer a better solution. The patch is in the org.apache.myfaces.custom.calendar.HtmlCalendarRenderer class within the encodeEnd() method.
Basically, this modification ensures that the UIInput.submittedValue attribute get reset to null upon successfully validated inputs - this breaks the persistance of erroneous values as described in the problem description. Additionally, in the case of errors, this fix reverts the value of the component and the associated submittedValue attribute to the previously submitted value. All of this amounts to making the UIInput.submittedValue attribute no longer store the state across submissions - the state is now only stored in the HtmlCalendarInput component's value attribute. This is not optimal, but does preserve the validation error messages which contains the erroneous submitted value in the text (so the user can see what happened) and also gets the user back to a workable state for their subsequent submissions.
To affect this work around, replace the following snippet from the encodeEnd() method:
try
{
// value = RendererUtils.getDateValue(inputCalendar);
Converter converter = getConverter(inputCalendar);
if (converter instanceof DateConverter)
{
value = ((DateConverter) converter).getAsDate(facesContext, component);
}
else
{
value = RendererUtils.getDateValue(inputCalendar);
}
}
catch (IllegalArgumentException illegalArgumentException)
{
value = null;
}
With the following:
try
{
// value = RendererUtils.getDateValue(inputCalendar);
Converter converter = getConverter(inputCalendar);
if (converter instanceof DateConverter)
{
value = ((DateConverter) converter).getAsDate(facesContext, component);
}
else
{
value = RendererUtils.getDateValue(inputCalendar);
}
// patch: start
((HtmlInputText) component).setSubmittedValue( null );
// patch: end
}
catch (IllegalArgumentException illegalArgumentException)
{
// patch: start
if ( ((javax.faces.component.ValueHolder) component).getValue() != null )
{
value = (Date) ((javax.faces.component.ValueHolder) component).getValue();
}
else
{
value = null;
}
((HtmlInputText) component).setSubmittedValue( null );
// patch: end
}
I'll attach the following in a pathced version to this bug.
> <t:inputCalendar> does not completely recover from submitted date/time formatting/validation errors
> ---------------------------------------------------------------------------------------------------
>
> Key: TOMAHAWK-1104
> URL: https://issues.apache.org/jira/browse/TOMAHAWK-1104
> Project: MyFaces Tomahawk
> Issue Type: Bug
> Components: Calendar
> Affects Versions: 1.1.6
> Environment: Windows XP, IE 6, MyFaces 1.1.5, Tomahawk 1.1.6
> Reporter: Todd Gould
>
> There appears to be a problem with the <t:inutCalendar> component recovering from user entry errors. For example, if I am using the following tag in a JSP:
> <t:inputCalendar id="SinceAlertTime"
> value="#{alertSummaryController.sinceTime}"
> popupDateFormat="MM/dd/yyyy HH:mm:ss" helpText="MM/dd/yyyy HH:mm:ss"
> title="MM/dd/yyyy HH:mm:ss"
> popupSelectDateMessage="Select [date] as date"
> renderAsPopup="true" renderPopupButtonAsImage="true">
> All works as desired unless the user manually enters an invalid date/time format (for example a typo) in the associated text entry field generated by this component. In this case the scenario is as follows:
> 1. The user inadvertently enters a bad date/time format into the associated text entry field and subsequently submits the form.
> 2. The validation error is correctly created and displayed back to the user (validation failed, so Invoke Application phase never performed).
> 3. The user then corrects their error by either manually entering a valid format in the associated text entry field or by invoking the popup and selecting a date.
> 4. The user then submits the form and the now corrected date is apparently accepted (i.e. no validation error). However, the previously invalid value is retained as the backing bean is not set and the resulting text entry field displayed contains the user entered invalid date/time format upon redisplay.
> We are using CLIENT state saving method as our ajax implementation relies upon this. I have not had a chance to see if that matters or not, but submit it for complete information.
> This is a severe problem for us as our user community frequently uses both the popup to select a date and then subsequently manually adjusts the time portion in the text entry field. If they inadvertantly create an invalid entry in this fashion, they are basically stuck as the component does not appear to recover upon re-submission of valid date/time values in the associated text entry field - i.e. the error keeps re-appearing upon subsequent submissions.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TOMAHAWK-1104) does not
completely recover from submitted date/time formatting/validation errors
Posted by "Todd Gould (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/TOMAHAWK-1104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12556604#action_12556604 ]
Todd Gould commented on TOMAHAWK-1104:
--------------------------------------
Simon,
Thanks for your input on this issue. I suspect you 'wild guess' is dead on. Our pages are a composition of multiple collaborating webapps concurrently displayed on the same browser screen (enabled via extensive use of AjaxAnywhere). Therefore, there are always multiple forms on the screen at the same time. Are you aware of anyway that we could either 1) ensure that the "enter" button triggers the form associated to the one the control is declared in or 2) ensure that the inputDate data does get posted?
TIA!
> <t:inputCalendar> does not completely recover from submitted date/time formatting/validation errors
> ---------------------------------------------------------------------------------------------------
>
> Key: TOMAHAWK-1104
> URL: https://issues.apache.org/jira/browse/TOMAHAWK-1104
> Project: MyFaces Tomahawk
> Issue Type: Bug
> Components: Calendar
> Affects Versions: 1.1.6
> Environment: Windows XP, IE 6, MyFaces 1.1.5, Tomahawk 1.1.6
> Reporter: Todd Gould
> Attachments: HtmlCalendarRenderer.java
>
>
> There appears to be a problem with the <t:inutCalendar> component recovering from user entry errors. For example, if I am using the following tag in a JSP:
> <t:inputCalendar id="SinceAlertTime"
> value="#{alertSummaryController.sinceTime}"
> popupDateFormat="MM/dd/yyyy HH:mm:ss" helpText="MM/dd/yyyy HH:mm:ss"
> title="MM/dd/yyyy HH:mm:ss"
> popupSelectDateMessage="Select [date] as date"
> renderAsPopup="true" renderPopupButtonAsImage="true">
> All works as desired unless the user manually enters an invalid date/time format (for example a typo) in the associated text entry field generated by this component. In this case the scenario is as follows:
> 1. The user inadvertently enters a bad date/time format into the associated text entry field and subsequently submits the form.
> 2. The validation error is correctly created and displayed back to the user (validation failed, so Invoke Application phase never performed).
> 3. The user then corrects their error by either manually entering a valid format in the associated text entry field or by invoking the popup and selecting a date.
> 4. The user then submits the form and the now corrected date is apparently accepted (i.e. no validation error). However, the previously invalid value is retained as the backing bean is not set and the resulting text entry field displayed contains the user entered invalid date/time format upon redisplay.
> We are using CLIENT state saving method as our ajax implementation relies upon this. I have not had a chance to see if that matters or not, but submit it for complete information.
> This is a severe problem for us as our user community frequently uses both the popup to select a date and then subsequently manually adjusts the time portion in the text entry field. If they inadvertantly create an invalid entry in this fashion, they are basically stuck as the component does not appear to recover upon re-submission of valid date/time values in the associated text entry field - i.e. the error keeps re-appearing upon subsequent submissions.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TOMAHAWK-1104) does not
completely recover from submitted date/time formatting/validation errors
Posted by "Todd Gould (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/TOMAHAWK-1104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Todd Gould updated TOMAHAWK-1104:
---------------------------------
Status: Open (was: Patch Available)
> <t:inputCalendar> does not completely recover from submitted date/time formatting/validation errors
> ---------------------------------------------------------------------------------------------------
>
> Key: TOMAHAWK-1104
> URL: https://issues.apache.org/jira/browse/TOMAHAWK-1104
> Project: MyFaces Tomahawk
> Issue Type: Bug
> Components: Calendar
> Affects Versions: 1.1.6
> Environment: Windows XP, IE 6, MyFaces 1.1.5, Tomahawk 1.1.6
> Reporter: Todd Gould
>
> There appears to be a probelm with the <t:inutCalendar> component recovering from user entry errors. For example, if I am using the following tag in a JSP:
> <t:inputCalendar id="SinceAlertTime"
> value="#{alertSummaryController.sinceTime}"
> popupDateFormat="MM/dd/yyyy HH:mm:ss" helpText="MM/dd/yyyy HH:mm:ss"
> title="MM/dd/yyyy HH:mm:ss"
> popupSelectDateMessage="Select [date] as date"
> renderAsPopup="true" renderPopupButtonAsImage="true">
> All works as desired unless the user manually enters an invalid date/time format (for example a typo) in the associated text entry field generated by this component. In this case the scenario is as follows:
> 1. The user inadvertently enters a bad date/time format into the associated text entry field and subsequently submits the form.
> 2. The validation error is correctly created and displayed back to the user (validation failed, so Invoke Application phase never performed).
> 3. The user then corrects their error by either manually entering a valid format in the associated text entry field or by invoking the popup and selecting a date.
> 4. The user then submits the form and the now corrected date is apparently accepted (i.e. no validation error). However, the previously unvalid value is retained as the backing bean is not set and the resulting display contains the user entered invalid date/time format upon redisplay.
> We are using CLIENT stat saving method as our ajax implementation relies upon this. If have not had a chance to see if that matters, but submit it for complete information.
> This is a severe problem for us as our user community frequently uses both the popup to select a date and then subsequently manually adjusts the time portion in the text entry field. If they inadvertantly creat and invalid entry in this fashion, they are basically stuck as there the component does not appear to recover upon re-submission of valid date/time values in the associated text entry field - i.e. the error keeps re-appearing upon subsequent submissions.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TOMAHAWK-1104) does not
completely recover from submitted date/time formatting/validation errors
Posted by "Simon Kitching (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/TOMAHAWK-1104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12556387#action_12556387 ]
Simon Kitching commented on TOMAHAWK-1104:
------------------------------------------
Hi Todd,
Sorry but I cannot duplicate your problem. There is an installation of the tomahawk examples on the web. Here is a link to the "calendar" demo page:
http://www.irian.at/myfacesexamples/calendar.jsf
It isn't a great demo, but it is sufficient to test your issue I think. Note that in the row of popup calendars, both popups are actually linked to the same backing bean property.
Click the second popup button, and select a date from the popup calendar. Now click submit. You can see that the first box changes, ie the property really has been set on the backing bean. Now enter an invalid date manually into the field associated with the second popup calendar, and submit. An error message is displayed at the top of the screen as expected, and the second input field displays that bad submitted value. Now correct that bad date and submit. You can see that the validation message disappears and the first date changes to match, ie the data is successfully being pushed into the backing bean.
I can't think why you would be seeing something else.
Re your debugging, what you see with the invalid submittedValue being restored is expected. On restore of the view tree, the submittedValue is set to what was last known to the server (the bad value from the previous submit). Then each component in the tree is asked to update itself from the values posted in the current submit; the inputDate component will therefore overwrite this bad value with the newly submitted one. That new submittedValue should then be successfully validated, converted, stored in the model, and finally set to null (to indicate that the data from the model should be used when rendering).
The restored (bad) submittedValue is not overwritten only in the case where the submitted form does not post data for that inputDate component (eg the page has multiple forms).
Maybe your page has multiple forms, and when the users try to correct a bad date they then hit "enter" which triggers a submit button in a form other than the one the inputCalendar is in? (wild guess..)
> <t:inputCalendar> does not completely recover from submitted date/time formatting/validation errors
> ---------------------------------------------------------------------------------------------------
>
> Key: TOMAHAWK-1104
> URL: https://issues.apache.org/jira/browse/TOMAHAWK-1104
> Project: MyFaces Tomahawk
> Issue Type: Bug
> Components: Calendar
> Affects Versions: 1.1.6
> Environment: Windows XP, IE 6, MyFaces 1.1.5, Tomahawk 1.1.6
> Reporter: Todd Gould
> Attachments: HtmlCalendarRenderer.java
>
>
> There appears to be a problem with the <t:inutCalendar> component recovering from user entry errors. For example, if I am using the following tag in a JSP:
> <t:inputCalendar id="SinceAlertTime"
> value="#{alertSummaryController.sinceTime}"
> popupDateFormat="MM/dd/yyyy HH:mm:ss" helpText="MM/dd/yyyy HH:mm:ss"
> title="MM/dd/yyyy HH:mm:ss"
> popupSelectDateMessage="Select [date] as date"
> renderAsPopup="true" renderPopupButtonAsImage="true">
> All works as desired unless the user manually enters an invalid date/time format (for example a typo) in the associated text entry field generated by this component. In this case the scenario is as follows:
> 1. The user inadvertently enters a bad date/time format into the associated text entry field and subsequently submits the form.
> 2. The validation error is correctly created and displayed back to the user (validation failed, so Invoke Application phase never performed).
> 3. The user then corrects their error by either manually entering a valid format in the associated text entry field or by invoking the popup and selecting a date.
> 4. The user then submits the form and the now corrected date is apparently accepted (i.e. no validation error). However, the previously invalid value is retained as the backing bean is not set and the resulting text entry field displayed contains the user entered invalid date/time format upon redisplay.
> We are using CLIENT state saving method as our ajax implementation relies upon this. I have not had a chance to see if that matters or not, but submit it for complete information.
> This is a severe problem for us as our user community frequently uses both the popup to select a date and then subsequently manually adjusts the time portion in the text entry field. If they inadvertantly create an invalid entry in this fashion, they are basically stuck as the component does not appear to recover upon re-submission of valid date/time values in the associated text entry field - i.e. the error keeps re-appearing upon subsequent submissions.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.