Details
-
Type:
Bug
-
Status: Open
-
Priority:
Major
-
Resolution: Unresolved
-
Affects Version/s: 4.0
-
Fix Version/s: None
-
Component/s: ACE-Components
-
Labels:None
-
Environment:Icefaces 4.0 and abandoned 3.3 from trunk
Description
Old version of ace:dateTimeEntry in Icefaces 3.3 from march 2013
generates short calendar responses for locales defined already in javascript.
Current version generates much longer responses with month and day names. Previous solution was better and new should be an option.
At this moment this unnecessary response is repeated with 1440 bytes overhead for each calendar occurence.
generates short calendar responses for locales defined already in javascript.
Current version generates much longer responses with month and day names. Previous solution was better and new should be an option.
At this moment this unnecessary response is repeated with 1440 bytes overhead for each calendar occurence.
Activity
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
Attached image of error in showcase / /datelocale.xhtml for control changed to
<ace:dateTimeEntry id="calLocale" locale="#
"
value="#
" timeOnly="both"
timeZone="Canada/Mountain"
pattern="MMMM dd, yyyy h:mm:ss "/>
Show
Krashan Brahmanjara
added a comment - Attached image of error in showcase / /datelocale.xhtml for control changed to
<ace:dateTimeEntry id="calLocale" locale="#
{dateLocale.locale}
"
value="#
{dateLocale.selectedDate}
" timeOnly="both"
timeZone="Canada/Mountain"
pattern="MMMM dd, yyyy h:mm:ss "/>
The problem is with changed ice.ace.locales handling. Current solution is universal but ineffective. Additionaly it didn't work with timeOnly="both" setting.
I can recommend to fix this problem with backward compatibile way as Icefaces 3.3 and Primefaces do. Locale response should be generated if user want. Otherwise code with ice.ace.locales array should be used.