[
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.
