[jira] Commented: (TOMAHAWK-1104) does not completely recover from submitted date/time formatting/validation errors

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