[TRINIDAD-1950] Null pattern handling in DateTimeConverter is inconsistent

• Type: Bug
• Status: Resolved
• Priority: Minor
• Resolution: Fixed
• Affects Version/s: 2.0.0-beta-1
• Fix Version/s: 2.0.0-beta-1
• Component/s: Components
• Environment: Linux x86
• Assignee: Gabrielle Crawford
• Reporter: Kentaro Kinebuchi
• Created: 02/Nov/10 19:03
• Updated: 13/Jan/11 11:56
• Resolved: 19/Nov/10 19:18

Description

For null patterns, the getPattern() method in DateTimeConverter returns null in non-Facelets and empty string in Facelets due to TRINIDAD-381. This is causing inconsistent behavior depending on whether Facelets or non-Facelets is used. Some of the code in DateTimeConverter does attempt to handle both null and empty string patters such as in _getDateFormat() but most of the methods simply check if the pattern is null. It is better to modify getPattern() to always return null when pattern is either null or empty string.
One example of a problem this inconsistent handling of pattern is causing is that when we have a DateTime component such as:

<af:inputDate value="#

{bindings.Hiredate.inputValue}

"
label="#

{bindings.Hiredate.hints.label}

"
required="#

{bindings.Hiredate.hints.mandatory}

"
shortDesc="#

{bindings.Hiredate.hints.tooltip}

" id="id1">
<f:validator binding="#

{bindings.Hiredate.validator}

"/>
<af:convertDateTime pattern="#

{bindings.Hiredate.format}

"/>
</af:inputDate>

And pattern is null then depending on whether we are using Facelets or non-Facelets when the user picks a date value it ends up getting formatted differently. And it's happening because getJSPattern() in DateTimeConverter only checks for null.