[jira] [Commented] (TRINIDAD-2504) DateFormat.js incorrectly implements 'D' (day of year) parsing
[ https://issues.apache.org/jira/browse/TRINIDAD-2504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14140025#comment-14140025 ] Yee-Wah Lee commented on TRINIDAD-2504: --- Further fixes have been made in Trinidad-2509, consumers of this fix should also include the changes there. DateFormat.js incorrectly implements 'D' (day of year) parsing -- Key: TRINIDAD-2504 URL: https://issues.apache.org/jira/browse/TRINIDAD-2504 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.1.0-core Reporter: Yee-Wah Lee Priority: Minor Fix For: 2.1.1-core Attachments: trin_2504_DateFormatDayOfYear.diff 1. Create an inputDate with a converter that uses 'D' (day of year) pattern and no initial value e.g. tr:inputDate id='id1' tr:convertDateTime pattern='DDD'/ /tr:inputDate 2. Run the demo and pick the 1st of January (any year) 3. The input shows 355, the correct value should be 1. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TRINIDAD-2504) DateFormat.js incorrectly implements 'D' (day of year) parsing
Yee-Wah Lee created TRINIDAD-2504: - Summary: DateFormat.js incorrectly implements 'D' (day of year) parsing Key: TRINIDAD-2504 URL: https://issues.apache.org/jira/browse/TRINIDAD-2504 Project: MyFaces Trinidad Issue Type: Bug Components: Components Reporter: Yee-Wah Lee Priority: Minor 1. Create an inputDate with a converter that uses 'D' (day of year) pattern and no initial value e.g. tr:inputDate id='id1' tr:convertDateTime pattern='DDD'/ /tr:inputDate 2. Run the demo and pick the 1st of January (any year) 3. The input shows 355, the correct value should be 1. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TRINIDAD-2504) DateFormat.js incorrectly implements 'D' (day of year) parsing
[ https://issues.apache.org/jira/browse/TRINIDAD-2504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14087269#comment-14087269 ] Yee-Wah Lee commented on TRINIDAD-2504: --- DateFormat.js parse() method was incompletely implemented - it parsed the number, but did not set the parseContext fields. Hence the parsed Date would always be the same defaults, i.e. 12/1/1969 16:00 (local timezone), see _simpleDateParseImpl() for defaulting code. Attaching a patch that would implement parsing for 'D'. It requires the year to be parsed/defaulted first, so it sits outside the _simpleParse routine. DateFormat.js incorrectly implements 'D' (day of year) parsing -- Key: TRINIDAD-2504 URL: https://issues.apache.org/jira/browse/TRINIDAD-2504 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.1.0-core Reporter: Yee-Wah Lee Priority: Minor 1. Create an inputDate with a converter that uses 'D' (day of year) pattern and no initial value e.g. tr:inputDate id='id1' tr:convertDateTime pattern='DDD'/ /tr:inputDate 2. Run the demo and pick the 1st of January (any year) 3. The input shows 355, the correct value should be 1. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (TRINIDAD-2405) Allow numberConverter to specify roundingmode
Yee-Wah Lee created TRINIDAD-2405: - Summary: Allow numberConverter to specify roundingmode Key: TRINIDAD-2405 URL: https://issues.apache.org/jira/browse/TRINIDAD-2405 Project: MyFaces Trinidad Issue Type: Improvement Reporter: Yee-Wah Lee NumberFormat has a method setRoundingMode() which controls how numbers are rounded. The JDK default is RoundingMode.HALF_EVEN. This tracks adding an attribute to the numberConverter so that the rounding mode can be set, instead of always using JDK defaults. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TRINIDAD-2386) Client dateTimeConverter overly strict, restricts years to max 4 digits
Yee-Wah Lee created TRINIDAD-2386: - Summary: Client dateTimeConverter overly strict, restricts years to max 4 digits Key: TRINIDAD-2386 URL: https://issues.apache.org/jira/browse/TRINIDAD-2386 Project: MyFaces Trinidad Issue Type: Bug Reporter: Yee-Wah Lee Priority: Minor 1. Go to http://example.irian.at/trinidad-demo/faces/convertValidate/clientConvert.jspx 2. In the date converter, enter a date with 5 digit years, e.g. 5/31/20139 3. Click Submit - get error about the date being in the incorrect format -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TRINIDAD-2386) Client dateTimeConverter overly strict, restricts years to max 4 digits
[ https://issues.apache.org/jira/browse/TRINIDAD-2386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13660065#comment-13660065 ] Yee-Wah Lee commented on TRINIDAD-2386: --- The date converter's _subparse method calls _accumulateNumber with maxLength=4. This means that years are at most 4 digits long. However, this is stricter than the server. Javascript accepts a wider range than 4 digit years, the range accepted is 6 digits long. http://stackoverflow.com/questions/11526504/minimum-and-maximum-date Client dateTimeConverter overly strict, restricts years to max 4 digits --- Key: TRINIDAD-2386 URL: https://issues.apache.org/jira/browse/TRINIDAD-2386 Project: MyFaces Trinidad Issue Type: Bug Reporter: Yee-Wah Lee Priority: Minor 1. Go to http://example.irian.at/trinidad-demo/faces/convertValidate/clientConvert.jspx 2. In the date converter, enter a date with 5 digit years, e.g. 5/31/20139 3. Click Submit - get error about the date being in the incorrect format -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TRINIDAD-2385) trinidad-config documentation wrong for time-zone parameter defaulting
Yee-Wah Lee created TRINIDAD-2385: - Summary: trinidad-config documentation wrong for time-zone parameter defaulting Key: TRINIDAD-2385 URL: https://issues.apache.org/jira/browse/TRINIDAD-2385 Project: MyFaces Trinidad Issue Type: Bug Reporter: Yee-Wah Lee Priority: Minor The documentation for time-zone defaulting in this link is incorrect: http://myfaces.apache.org/trinidad/devguide/configuration.html#trinidad-config.xml The code does not attempt to guess the user's timezone. Instead, it defaults to the value returned by JDK TimeZone.getDefault -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TRINIDAD-2381) Add header tags h1..h6 support to XhtmlFormattedText
Yee-Wah Lee created TRINIDAD-2381: - Summary: Add header tags h1..h6 support to XhtmlFormattedText Key: TRINIDAD-2381 URL: https://issues.apache.org/jira/browse/TRINIDAD-2381 Project: MyFaces Trinidad Issue Type: Improvement Components: Components Reporter: Yee-Wah Lee Priority: Minor Allow components which use the XhtmlFormattedText (e.g. outputFormatted) to support the HTML header tags h1..h6 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TRINIDAD-2357) TrNumberConverter performs parseFloat for all numbers, including integers
Yee-Wah Lee created TRINIDAD-2357: - Summary: TrNumberConverter performs parseFloat for all numbers, including integers Key: TRINIDAD-2357 URL: https://issues.apache.org/jira/browse/TRINIDAD-2357 Project: MyFaces Trinidad Issue Type: Bug Reporter: Yee-Wah Lee Priority: Minor NumberConverter.js does: parsedValue = parseFloat(parsedValue.toFixed(this._numberFormat.getMaximumFractionDigits())); The parsed value is converted to a String and is re-parsed as a float. This is because toFixed sets the decimals properly, but toFixed returns a string, so it then has to call parseFloat to turn it back into a number. However, for integerOnly=true, this is causing a side effect on WebDriver, IE+Windows 7. InternetExplorer on Windows 7 somehow treats all numbers resulting out of a parseFloat's string as a decimal (a whole number resulting from parseFloat is still a decimal in IE+Win7), and WebDriver dutifully marshalls it to Double. Solution: do a conditional parseFloat by querying isIntegerOnly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TRINIDAD-2354) convertNumber type=percent server and client results differ.
Yee-Wah Lee created TRINIDAD-2354: - Summary: convertNumber type=percent server and client results differ. Key: TRINIDAD-2354 URL: https://issues.apache.org/jira/browse/TRINIDAD-2354 Project: MyFaces Trinidad Issue Type: Bug Reporter: Yee-Wah Lee Priority: Minor 1. Create an inputText with child numberConverter, type=percent. Or, see example here: http://example.irian.at/trinidad-demo/faces/convertValidate/convertValidate.jspx 2. Enter 2.75 into the input field and Submit 2a. The client converter initially changes it to 2.75% 2b. After the server returns, it displays as 3%. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TRINIDAD-2354) convertNumber type=percent server and client results differ.
[
https://issues.apache.org/jira/browse/TRINIDAD-2354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13562084#comment-13562084
]
Yee-Wah Lee commented on TRINIDAD-2354:
---
On the server, creating a NumberFormat with type= percent has maxFractionDigits
= 0
However, on the client, the default maxFractionDigits=3. So the defaults need
to be changed in TrNumberFormat() constructor.
Also, the following code which creates a NumberFormat instance to parse the
percent/currency string should copy the max/min Integer/FractionDigits values.
TrNumberConverter_getAsObject()
{
// The user could have just left off the percent/currency symbol, so try
parsing 'numberString' as a Number instead; if it still fails, then
// throw a converter exception.
try
{
numberString =
TrNumberFormat.getNumberInstance().parse(numberString)+;
}
}
convertNumber type=percent server and client results differ.
-
Key: TRINIDAD-2354
URL: https://issues.apache.org/jira/browse/TRINIDAD-2354
Project: MyFaces Trinidad
Issue Type: Bug
Reporter: Yee-Wah Lee
Priority: Minor
1. Create an inputText with child numberConverter, type=percent. Or, see
example here:
http://example.irian.at/trinidad-demo/faces/convertValidate/convertValidate.jspx
2. Enter 2.75 into the input field and Submit
2a. The client converter initially changes it to 2.75%
2b. After the server returns, it displays as 3%.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TRINIDAD-2342) Facelets: Need metadata rule to convert String-Color, String-ListColor
Yee-Wah Lee created TRINIDAD-2342: - Summary: Facelets: Need metadata rule to convert String-Color, String-ListColor Key: TRINIDAD-2342 URL: https://issues.apache.org/jira/browse/TRINIDAD-2342 Project: MyFaces Trinidad Issue Type: Bug Reporter: Yee-Wah Lee Priority: Minor inputColor allows its value attribute to be specified as a #RRGGBB string instead of Color object. chooseColor allows its colorData attribute to be specified as a String of #RRGGBB instead of ListColor. The code to convert these is in TagUtils, but has not been ported to Facelets. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TRINIDAD-2338) client tr:numberconverter uses the page locale instead of converter locale to parse a number
Yee-Wah Lee created TRINIDAD-2338:
-
Summary: client tr:numberconverter uses the page locale instead of
converter locale to parse a number
Key: TRINIDAD-2338
URL: https://issues.apache.org/jira/browse/TRINIDAD-2338
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Affects Versions: 2.0.1-core
Reporter: Yee-Wah Lee
Priority: Minor
1) Use the following jspx:
tr:inputText label=numberConverter, ar locale value =
#{converterValidator.negDoubleValue1}
tr:convertNumber type=number locale=ar/
/tr:inputText
tr:commandButton text=Submit/
where negDoubleValue1 returns a negative double.
2) Load the page with a non-AR locale, e.g. en_US
3) Run the page, and modify a digitin the negDouble value (so it is still
valid). Submit the page - It throws an error about being an invalid number.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TRINIDAD-2338) client tr:numberconverter uses the page locale instead of converter locale to parse a number
[
https://issues.apache.org/jira/browse/TRINIDAD-2338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13492506#comment-13492506
]
Yee-Wah Lee commented on TRINIDAD-2338:
---
The client numberConverter is using the page (en) locale so it does not
recognize the number formatted in Arabic (even though it is valid).
client tr:numberconverter uses the page locale instead of converter locale to
parse a number
Key: TRINIDAD-2338
URL: https://issues.apache.org/jira/browse/TRINIDAD-2338
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Affects Versions: 2.0.1-core
Reporter: Yee-Wah Lee
Priority: Minor
1) Use the following jspx:
tr:inputText label=numberConverter, ar locale value =
#{converterValidator.negDoubleValue1}
tr:convertNumber type=number locale=ar/
/tr:inputText
tr:commandButton text=Submit/
where negDoubleValue1 returns a negative double.
2) Load the page with a non-AR locale, e.g. en_US
3) Run the page, and modify a digitin the negDouble value (so it is still
valid). Submit the page - It throws an error about being an invalid number.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TRINIDAD-2331) convertNumber component does not work with target type of BigInteger
Yee-Wah Lee created TRINIDAD-2331:
-
Summary: convertNumber component does not work with target type of
BigInteger
Key: TRINIDAD-2331
URL: https://issues.apache.org/jira/browse/TRINIDAD-2331
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Affects Versions: 2.0.1-core
Reporter: Yee-Wah Lee
Priority: Minor
af:inputText label=BigInteger number converter
value=#{testValidate.bigInt}
id=bigintegernumberconverter
af:convertNumber/
/af:inputText
Bind testValidate.bigInt to return an instance of java.math.BigInteger.
The converter will fail with TypeConversionException even though isAssignable()
returns true. This is because the convert() method does not implement the
conversion. The fix should be similar to Trinidad-372 for BigDecimal.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TRINIDAD-2283) Unexpected value change with 2 digit defaulting in dateTimeConverter
Yee-Wah Lee created TRINIDAD-2283: - Summary: Unexpected value change with 2 digit defaulting in dateTimeConverter Key: TRINIDAD-2283 URL: https://issues.apache.org/jira/browse/TRINIDAD-2283 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.0.1-core Reporter: Yee-Wah Lee Priority: Minor 1. Create an inputText with a convertDateTime uses two-digit year patterns, e.g. convertdateTime pattern=dd/MM/yy 2. Set the inputText value to a date that falls outside the default two-digit-year-start in trinidad-config.xml. The default value is 1950, so two-digit-years would usually resolve within [1950, 2050]. For example, set the date to 1/1/1377. 3. Run the jspx, see that the value is 1/1/77. 4. Modify it to 1/1/78 and submit. Observe that the value changes to 1/1/1978. This is unexpected for the user who did not enter the century change (and also cannot see the effects). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TRINIDAD-2281) DateConverter to default year if not specified
Yee-Wah Lee created TRINIDAD-2281: - Summary: DateConverter to default year if not specified Key: TRINIDAD-2281 URL: https://issues.apache.org/jira/browse/TRINIDAD-2281 Project: MyFaces Trinidad Issue Type: Improvement Reporter: Yee-Wah Lee Priority: Minor If the convertDateTime pattern expects a year, and the user has typed in day and month, client dateTimeConverter can default the year to the current year. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TRINIDAD-2139) Client NumberConverter with type=percent ignores maxfractiondigits when formatting
[
https://issues.apache.org/jira/browse/TRINIDAD-2139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13104665#comment-13104665
]
Yee-Wah Lee commented on TRINIDAD-2139:
---
The Math.round code appears to have been there since the numberConverter was
first created, it appears to be an overlooked when later fixes were made for
maxFractionDigits.
The getRounded call can be removed, since numberToString will take into account
min/maxFractionDigits.
Client NumberConverter with type=percent ignores maxfractiondigits when
formatting
--
Key: TRINIDAD-2139
URL: https://issues.apache.org/jira/browse/TRINIDAD-2139
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Affects Versions: 2.0.0
Reporter: Yee-Wah Lee
Priority: Minor
NumberFormat.js contains the following code:
TrNumberFormat.prototype.percentageToString = function(number)
{
number = number * 100;
number = this.getRounded(number);
.. number = this.numberToString(number);
}
consideration the number of fractionDigits but numberToString later will.
TrNumberFormat.prototype.getRounded = function(val)
{
val = this.moveDecimalRight(val);
val = Math.round(val);
val = this.moveDecimalLeft(val);
return val;
}
Math.round function will round to the nearest integer. With the earlier
multiplication to 100, precision is preserved to at most two digits,
regardless of the maxFractionDigits attribute.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (TRINIDAD-2139) Client NumberConverter with type=percent ignores maxfractiondigits when formatting
[
https://issues.apache.org/jira/browse/TRINIDAD-2139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13104696#comment-13104696
]
Yee-Wah Lee edited comment on TRINIDAD-2139 at 9/14/11 5:51 PM:
Trinidad-2139 patch for trunk and 1.2.12.6.0 branch
was (Author: yeelee):
Trunk patch for Trinidad-2139
Client NumberConverter with type=percent ignores maxfractiondigits when
formatting
--
Key: TRINIDAD-2139
URL: https://issues.apache.org/jira/browse/TRINIDAD-2139
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Affects Versions: 2.0.0
Reporter: Yee-Wah Lee
Priority: Minor
Attachments: trunk_2139_numberPercentMaxFrac.diff
NumberFormat.js contains the following code:
TrNumberFormat.prototype.percentageToString = function(number)
{
number = number * 100;
number = this.getRounded(number);
.. number = this.numberToString(number);
}
consideration the number of fractionDigits but numberToString later will.
TrNumberFormat.prototype.getRounded = function(val)
{
val = this.moveDecimalRight(val);
val = Math.round(val);
val = this.moveDecimalLeft(val);
return val;
}
Math.round function will round to the nearest integer. With the earlier
multiplication to 100, precision is preserved to at most two digits,
regardless of the maxFractionDigits attribute.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TRINIDAD-2133) Support Thai Buddhist calendar in client DateTimeConverter
[
https://issues.apache.org/jira/browse/TRINIDAD-2133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yee-Wah Lee updated TRINIDAD-2133:
--
Status: Patch Available (was: Open)
Support Thai Buddhist calendar in client DateTimeConverter
--
Key: TRINIDAD-2133
URL: https://issues.apache.org/jira/browse/TRINIDAD-2133
Project: MyFaces Trinidad
Issue Type: Improvement
Components: Components
Affects Versions: 2.0.0
Reporter: Yee-Wah Lee
Priority: Minor
Attachments: branch121260_2133.diff,
trunk_2133_ThaiDateTimeConverter.diff
1. Create and run the following jspx
tr:inputText is d=dt autoSubmit=true value=#{input.date}
tr:convertDateTime locale=th_TH/
/tr:inputText
tr:outputText value=#{input.date} partialTriggers=dt
tr:convertDateTime locale=en_US/
/tr:outputText
2. The page will display the date using the Thai Buddhist Calendar, then the
date in US format (which uses GregorianCalendar on the server side). The Thai
Buddhist calendar is offset by 543 years from the Gregorain, e.g. the
inputText shows 22/8/2554 and the outputText shows 8/22/2011 .
3. Update the inputText to 29/2/2555 which is equivalent to 2/29/2012
Gregorian, a valid date. However this gives an error, Enter a valid date or
time.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TRINIDAD-2133) Support Thai Buddhist calendar in client DateTimeConverter
Support Thai Buddhist calendar in client DateTimeConverter
--
Key: TRINIDAD-2133
URL: https://issues.apache.org/jira/browse/TRINIDAD-2133
Project: MyFaces Trinidad
Issue Type: Improvement
Components: Components
Affects Versions: 2.0.0
Reporter: Yee-Wah Lee
Priority: Minor
1. Create and run the following jspx
tr:inputText is d=dt autoSubmit=true value=#{input.date}
tr:convertDateTime locale=th_TH/
/tr:inputText
tr:outputText value=#{input.date} partialTriggers=dt
tr:convertDateTime locale=en_US/
/tr:outputText
2. The page will display the date using the Thai Buddhist Calendar, then the
date in US format (which uses GregorianCalendar on the server side). The Thai
Buddhist calendar is offset by 543 years from the Gregorain, e.g. the inputText
shows 22/8/2554 and the outputText shows 8/22/2011 .
3. Update the inputText to 29/2/2555 which is equivalent to 2/29/2012
Gregorian, a valid date. However this gives an error, Enter a valid date or
time.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TRINIDAD-2133) Support Thai Buddhist calendar in client DateTimeConverter
[
https://issues.apache.org/jira/browse/TRINIDAD-2133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13089869#comment-13089869
]
Yee-Wah Lee commented on TRINIDAD-2133:
---
The convertDateTime uses the javascript Date APIs to create/validate the date,
however, JS still uses GregorianCalendar
http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-262%20edition%205.1,%20June%202011.pdf
To support this scenario, the convertDateTime peer would have to add/subtract
the year offset when displaying/parsing.
Support Thai Buddhist calendar in client DateTimeConverter
--
Key: TRINIDAD-2133
URL: https://issues.apache.org/jira/browse/TRINIDAD-2133
Project: MyFaces Trinidad
Issue Type: Improvement
Components: Components
Affects Versions: 2.0.0
Reporter: Yee-Wah Lee
Priority: Minor
1. Create and run the following jspx
tr:inputText is d=dt autoSubmit=true value=#{input.date}
tr:convertDateTime locale=th_TH/
/tr:inputText
tr:outputText value=#{input.date} partialTriggers=dt
tr:convertDateTime locale=en_US/
/tr:outputText
2. The page will display the date using the Thai Buddhist Calendar, then the
date in US format (which uses GregorianCalendar on the server side). The Thai
Buddhist calendar is offset by 543 years from the Gregorain, e.g. the
inputText shows 22/8/2554 and the outputText shows 8/22/2011 .
3. Update the inputText to 29/2/2555 which is equivalent to 2/29/2012
Gregorian, a valid date. However this gives an error, Enter a valid date or
time.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TRINIDAD-2126) convertdatetime fails with datestyle=full, th_th or ja_jp_jp locale
[
https://issues.apache.org/jira/browse/TRINIDAD-2126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13082748#comment-13082748
]
Yee-Wah Lee commented on TRINIDAD-2126:
---
Debugging, the era string used in the LocaleElements_th.js file do not match
the strings used by SimpleDateFormat. Thus the client converter fails to parse
the eras.
From discussion with Java folks it's known that DateFormatSymbols#getEras
returns a pair of strings for Gregorian calendar AD and BC even if locale is
set to
Thai or Japanese Imperial calendar. They think it's by design but need raise a
document bug.
To obtain eras for non Gregorian calendars, one need to use Calendar class like
following;
Calendar c = Calendar.getInstance(th);
String era = c.getDisplayName(Calendar.ERA, Calendar.LONG, th);
System.out.println(Calendar era: + era);
or
MapString, Integer eras = c.getDisplayNames(Calendar.ERA, Calendar.LONG,
th);
for ( String key : eras.keySet())
System.out.println(Calendar eras: + key);
convertdatetime fails with datestyle=full, th_th or ja_jp_jp locale
---
Key: TRINIDAD-2126
URL: https://issues.apache.org/jira/browse/TRINIDAD-2126
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components, Plugins
Affects Versions: 2.0.0
Reporter: Yee-Wah Lee
Priority: Minor
Create the following jspx:
tr:inputText id=it1 label=Label 1 value=#{input.date}
autoSubmit=true
tr:convertDateTime locale=th_TH dateStyle=full/
/tr:inputText
tr:outputText partialTriggers=it1 value=#{input.date}/
Run the page, and modify the date slightly so that it is still valid. Tab
off, get an error about the message not being in the correct format, though
the format itself did not change and the date is semantically valid.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TRINIDAD-2126) convertdatetime fails with datestyle=full, th_th or ja_jp_jp locale
convertdatetime fails with datestyle=full, th_th or ja_jp_jp locale
---
Key: TRINIDAD-2126
URL: https://issues.apache.org/jira/browse/TRINIDAD-2126
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Affects Versions: 2.0.0
Reporter: Yee-Wah Lee
Priority: Minor
Create the following jspx:
tr:inputText id=it1 label=Label 1 value=#{input.date}
autoSubmit=true
tr:convertDateTime locale=th_TH dateStyle=full/
/tr:inputText
tr:outputText partialTriggers=it1 value=#{input.date}/
Run the page, and modify the date slightly so that it is still valid. Tab
off, get an error about the message not being in the correct format, though
the format itself did not change and the date is semantically valid.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TRINIDAD-2104) Suppress warning when id set on converters
Suppress warning when id set on converters -- Key: TRINIDAD-2104 URL: https://issues.apache.org/jira/browse/TRINIDAD-2104 Project: MyFaces Trinidad Issue Type: Improvement Components: Components, Facelets Affects Versions: 2.0.0-beta-1 Reporter: Yee-Wah Lee Priority: Trivial Trinidad converters do not have id as a metadata attribute. However, in certain cases, the generated tld (see the maven plugins) specifies that id is supported. During design time, jdeveloper will expose this id and may programmatically set it for facelets pages, leading to warnings. Ignore this metadata to suppress the warning. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TRINIDAD-2104) Suppress warning when id set on converters
[ https://issues.apache.org/jira/browse/TRINIDAD-2104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yee-Wah Lee updated TRINIDAD-2104: -- Status: Patch Available (was: Open) Suppress warning when id set on converters -- Key: TRINIDAD-2104 URL: https://issues.apache.org/jira/browse/TRINIDAD-2104 Project: MyFaces Trinidad Issue Type: Improvement Components: Components, Facelets Affects Versions: 2.0.0-beta-1 Reporter: Yee-Wah Lee Priority: Trivial Attachments: Trinidad-2104.diff Trinidad converters do not have id as a metadata attribute. However, in certain cases, the generated tld (see the maven plugins) specifies that id is supported. During design time, jdeveloper will expose this id and may programmatically set it for facelets pages, leading to warnings. Ignore this metadata to suppress the warning. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TRINIDAD-2084) TrinidadConverterELTag does not convert ValueHolder value during initialization (regression)
[ https://issues.apache.org/jira/browse/TRINIDAD-2084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13020083#comment-13020083 ] Yee-Wah Lee commented on TRINIDAD-2084: --- The behavior in Trinidad follows the MyFaces Core implementation of ConverterELTag. The MyFaces Core behavior is actually correct because running the value through the converter would cause the component to behave differently across locales. For example, having inputText with value=5,000 and running in en locale would show 5000 for en, and 5 for fr locale. To keep the behavior consistent with MyFaces Core, I will close the issue. TrinidadConverterELTag does not convert ValueHolder value during initialization (regression) Key: TRINIDAD-2084 URL: https://issues.apache.org/jira/browse/TRINIDAD-2084 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.0.0-beta-2 Reporter: Yee-Wah Lee Assignee: Scott O'Bryan Priority: Minor Attachments: trunk_2084_TrinidadConverterELTag.diff This is seen since Trinidad-1898 1. Create the following jspx tr:inputNumberSpinbox label=Literal id=ins1a value=0.5 tr:convertNumber type=currency/ /tr:inputNumberSpinbox 2. Run the jspx, the input displays 0.5. Prior to Trinidad-1898, it would display ¤0.50. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TRINIDAD-2084) TrinidadConverterELTag does not convert ValueHolder value during initialization (regression)
TrinidadConverterELTag does not convert ValueHolder value during initialization (regression) Key: TRINIDAD-2084 URL: https://issues.apache.org/jira/browse/TRINIDAD-2084 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.0.0-beta-2 Reporter: Yee-Wah Lee Priority: Minor This is seen since Trinidad-1898 1. Create the following jspx tr:inputNumberSpinbox label=Literal id=ins1a value=0.5 tr:convertNumber type=currency/ /tr:inputNumberSpinbox 2. Run the jspx, the input displays 0.5. Prior to Trinidad-1898, it would display ¤0.50. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TRINIDAD-2084) TrinidadConverterELTag does not convert ValueHolder value during initialization (regression)
[
https://issues.apache.org/jira/browse/TRINIDAD-2084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13017073#comment-13017073
]
Yee-Wah Lee commented on TRINIDAD-2084:
---
Before Trinidad-1898, during ConverterELTag#doStartTag(), the following would
happen.
UIComponent component = tag.getComponentInstance();
ValueHolder vh = (ValueHolder)component;
Object localValue = vh.getLocalValue();
if (localValue instanceof String) {
try {
localValue = converter.getAsObject(context, (UIComponent)vh,
(String) localValue);
vh.setValue(localValue);
}
Hence, the component would take the string 0.5,convert it to a number and set
it on the component. Later, during rendering, getAsString() would take the
numerical value and format it with the currency code.
A new class TrinidadConverterELTag was introduced in Trinidad-1898, but it did
not contain the same code in doStartTag. It returned after setting the
converter on the valueHolder.
Converter converter = createConverter();
((ValueHolder)component).setConverter(converter);
return Tag.SKIP_BODY;
Subsequently, the component still has the value 0.5. During rendering,
getAsString() simply returns that string.
TrinidadConverterELTag does not convert ValueHolder value during
initialization (regression)
Key: TRINIDAD-2084
URL: https://issues.apache.org/jira/browse/TRINIDAD-2084
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Affects Versions: 2.0.0-beta-2
Reporter: Yee-Wah Lee
Priority: Minor
This is seen since Trinidad-1898
1. Create the following jspx
tr:inputNumberSpinbox label=Literal id=ins1a value=0.5
tr:convertNumber type=currency/
/tr:inputNumberSpinbox
2. Run the jspx, the input displays 0.5. Prior to Trinidad-1898, it would
display ¤0.50.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TRINIDAD-2084) TrinidadConverterELTag does not convert ValueHolder value during initialization (regression)
[ https://issues.apache.org/jira/browse/TRINIDAD-2084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yee-Wah Lee updated TRINIDAD-2084: -- Status: Patch Available (was: Open) TrinidadConverterELTag does not convert ValueHolder value during initialization (regression) Key: TRINIDAD-2084 URL: https://issues.apache.org/jira/browse/TRINIDAD-2084 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.0.0-beta-2 Reporter: Yee-Wah Lee Priority: Minor Attachments: trunk_2084_TrinidadConverterELTag.diff This is seen since Trinidad-1898 1. Create the following jspx tr:inputNumberSpinbox label=Literal id=ins1a value=0.5 tr:convertNumber type=currency/ /tr:inputNumberSpinbox 2. Run the jspx, the input displays 0.5. Prior to Trinidad-1898, it would display ¤0.50. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TRINIDAD-2076) Facelets: LocaleTagPropertyRule does not match jspx implementation
[ https://issues.apache.org/jira/browse/TRINIDAD-2076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yee-Wah Lee updated TRINIDAD-2076: -- Status: Patch Available (was: Open) Facelets: LocaleTagPropertyRule does not match jspx implementation --- Key: TRINIDAD-2076 URL: https://issues.apache.org/jira/browse/TRINIDAD-2076 Project: MyFaces Trinidad Issue Type: Bug Components: Facelets Affects Versions: 2.0.0-beta-2 Reporter: Yee-Wah Lee Priority: Minor Attachments: trunk_2076_LocaleTagPropertyRule.diff 1. Create a facelets page with a converter (e.g. numberConverter, dateTimeConverter) which has its locale attribute set to a language-country. tr:inputText label=ConvNumLocale: id=it1 tr:convertNumber type=currency locale=pt-BR/ /tr:inputText 2. Run the app, see the server log error. XhtmlUtils addLib Could not find scriptlet: LocaleInfo_pt-br 3. The component does not function because the Locale js file was not loaded. This is because LocaleTagPropertyRule creates a Locale thus in applyMetadata() : Locale loc = new Locale(_attribute.getValue(ctx)); which creates a Locale object with language=pt-br. However, the page is actually requesting a Locale with language=pt, country=br. Subsequently, it is unable to find the LocaleInfo scriptlet for the locale with language pt-br. In the jspx case, there is a helper method TagUtils#getLocale() which takes the string and create the Locale based on it. This correctly creates the Locale, and the request for LocaleInfo scriptlet succeeds. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TRINIDAD-2076) Facelets: LocaleTagPropertyRule does not match jspx implementation
Facelets: LocaleTagPropertyRule does not match jspx implementation --- Key: TRINIDAD-2076 URL: https://issues.apache.org/jira/browse/TRINIDAD-2076 Project: MyFaces Trinidad Issue Type: Bug Components: Facelets Affects Versions: 2.0.0-beta-2 Reporter: Yee-Wah Lee Priority: Minor 1. Create a facelets page with a converter (e.g. numberConverter, dateTimeConverter) which has its locale attribute set to a language-country. tr:inputText label=ConvNumLocale: id=it1 tr:convertNumber type=currency locale=pt-BR/ /tr:inputText 2. Run the app, see the server log error. XhtmlUtils addLib Could not find scriptlet: LocaleInfo_pt-br 3. The component does not function because the Locale js file was not loaded. This is because LocaleTagPropertyRule creates a Locale thus in applyMetadata() : Locale loc = new Locale(_attribute.getValue(ctx)); which creates a Locale object with language=pt-br. However, the page is actually requesting a Locale with language=pt, country=br. Subsequently, it is unable to find the LocaleInfo scriptlet for the locale with language pt-br. In the jspx case, there is a helper method TagUtils#getLocale() which takes the string and create the Locale based on it. This correctly creates the Locale, and the request for LocaleInfo scriptlet succeeds. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (TRINIDAD-2044) Mismatch between trinidad-config.xsd and documentation
Mismatch between trinidad-config.xsd and documentation -- Key: TRINIDAD-2044 URL: https://issues.apache.org/jira/browse/TRINIDAD-2044 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.0.0-beta-2 Reporter: Yee-Wah Lee Priority: Trivial The documentation for configuring trinidad lists the following which isn't in trinidad-config.xsd - two-digit-year-start Conversely, trinidad-config.xsd lists the following which isn't in the documentation - animation-enabled Link for documentation: http://myfaces.apache.org/trinidad/devguide/configuration.html -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (TRINIDAD-1958) Client tr:numberConverter with type=currency incorrectly handles arabic locale for positive values
[
https://issues.apache.org/jira/browse/TRINIDAD-1958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12992155#comment-12992155
]
Yee-Wah Lee commented on TRINIDAD-1958:
---
There is a JDK bug 6871307
http://monaco.sfbay.sun.com/detail.jsf?cr=6871307
But it was also pointed out that Windows uses the same format that JDK does,
and that either format might be acceptable.
Client tr:numberConverter with type=currency incorrectly handles arabic
locale for positive values
Key: TRINIDAD-1958
URL: https://issues.apache.org/jira/browse/TRINIDAD-1958
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Affects Versions: 1.2.13-core
Reporter: Yee-Wah Lee
Priority: Minor
1. Use the following jspx, binding the value of the inputText to a positive
integer.
tr:inputText label=InputText Arabic value=#{clientValidation.integer}
autoSubmit=true
tr:convertNumber type=currency locale=ar_SA/
/tr:inputText
tr:outputText value=Value submitted is
#{clientValidation.integer}/
2. Run the jspx, it displays something like:
2ر.س. 0
3. Modify just the numerical portion of the text and tab off: Get an
Incorrect Format error
Enter a currency in the same format as this example: ر.س. 10,250
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (TRINIDAD-1958) Client tr:numberConverter with type=currency incorrectly handles arabic locale for positive values
[
https://issues.apache.org/jira/browse/TRINIDAD-1958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12992169#comment-12992169
]
Yee-Wah Lee commented on TRINIDAD-1958:
---
Modified the stringToCurrency method in NumberFormat to check or both negative
prefix and suffix before going into the negative case. That seems to be
sufficient for the issue.
Client tr:numberConverter with type=currency incorrectly handles arabic
locale for positive values
Key: TRINIDAD-1958
URL: https://issues.apache.org/jira/browse/TRINIDAD-1958
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Affects Versions: 1.2.13-core
Reporter: Yee-Wah Lee
Priority: Minor
1. Use the following jspx, binding the value of the inputText to a positive
integer.
tr:inputText label=InputText Arabic value=#{clientValidation.integer}
autoSubmit=true
tr:convertNumber type=currency locale=ar_SA/
/tr:inputText
tr:outputText value=Value submitted is
#{clientValidation.integer}/
2. Run the jspx, it displays something like:
2ر.س. 0
3. Modify just the numerical portion of the text and tab off: Get an
Incorrect Format error
Enter a currency in the same format as this example: ر.س. 10,250
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (TRINIDAD-1967) DateTimeRangeValidator gives false failure if server specifies timezone attribute or timezone specified in trinidad-config.xml
DateTimeRangeValidator gives false failure if server specifies timezone
attribute or timezone specified in trinidad-config.xml
--
Key: TRINIDAD-1967
URL: https://issues.apache.org/jira/browse/TRINIDAD-1967
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Affects Versions: 1.2.13-core
Reporter: Yee-Wah Lee
This is a regression caused by Trinidad-1920. In that fix, an ISO-Date format
was used to create minISO/maxISO strings on the validator so the min/maxDate
could be sent down without loss of information. However the DateFormat was not
created with the timezone of the component converter, so it would send down
strings that specified different values causing false validation.
1. Modify the following example in trinidad-demo/clientConvert.jspx and run it
(this example uses Europe/Stockholm timezone, any TZ different from server JDK
timezone will suffice).
tr:inputText id=mdf5 value=#{date.date2}
label=date converter and a validator that
sets a maximum date of tonight
f:facet name=help
tr:outputText value=examples of values that will fail
validation: any date later than tonight 11:59 PM/
/f:facet
tr:convertDateTime type=both timezone=Europe/Stockholm/
tr:validateDateTimeRange
maximum=#{date.tonightNearMidnight}/
/tr:inputText
2. In the input box, type in the max (tonight 11:59pm),e.g. 12/2/2010 11:59pm
and Submit.
3. Get an error about failing validation although it is within bounds.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1967) DateTimeRangeValidator gives false failure if server specifies timezone attribute or timezone specified in trinidad-config.xml
[
https://issues.apache.org/jira/browse/TRINIDAD-1967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12966298#action_12966298
]
Yee-Wah Lee commented on TRINIDAD-1967:
---
Debugging notes.
Assume
- Server is running PST so maxDate = #{date.tonightNearMidnight} returns
2010-12-2 11:59pm PST
- The component converter, or trinidad-config.xml, specifies
timezone=Europe/Stockholm
1. trinidad-impl/DateTimeConverter.java#getClientValidation() returns
- maxStr = 12/3/2010 8:59am
- maxISOStr = 2010-12-2 11:59pm
2. CoreFormat.js, TrDateTimeRangeValidator.prototype.validate() does:
maxDate = isoConverter.getAsObject (this._maxISODate);
which returns the date of 2010-12-2 11:59pm. Comparing against what the user
enters (2010-12-3 8:59am), it gives a validation error that the value entered
is greater than the maximum, so the client is being stricter than the server
which would accept up to 2010-12-3 8:5am (GMT+1).
DateTimeRangeValidator gives false failure if server specifies timezone
attribute or timezone specified in trinidad-config.xml
--
Key: TRINIDAD-1967
URL: https://issues.apache.org/jira/browse/TRINIDAD-1967
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Affects Versions: 1.2.13-core
Reporter: Yee-Wah Lee
This is a regression caused by Trinidad-1920. In that fix, an ISO-Date
format was used to create minISO/maxISO strings on the validator so the
min/maxDate could be sent down without loss of information. However the
DateFormat was not created with the timezone of the component converter, so
it would send down strings that specified different values causing false
validation.
1. Modify the following example in trinidad-demo/clientConvert.jspx and run
it (this example uses Europe/Stockholm timezone, any TZ different from server
JDK timezone will suffice).
tr:inputText id=mdf5 value=#{date.date2}
label=date converter and a validator
that sets a maximum date of tonight
tr:convertDateTime type=both timezone=Europe/Stockholm/
tr:validateDateTimeRange
maximum=#{date.tonightNearMidnight}/
/tr:inputText
2. If you have a hint on the validator, it would display max with the
timezone of the converter. For example, if server is PST, and I'm running on
2010-12-2, the maxDate created is 2010-12-2 11:59 pm PST which converts to
2010-12-3 8:59am (GMT+1). So the maximum I can enter on the client is
12/3/2010 8:59am.
3. In the input box, type in the max and Submit. Get an error about
failing validation although it is within bounds.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1920) DateTimeRangevalidator fails across multiple timezones
[ https://issues.apache.org/jira/browse/TRINIDAD-1920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12966300#action_12966300 ] Yee-Wah Lee commented on TRINIDAD-1920: --- See Trinidad-1967 for an update of this fix. DateTimeRangevalidator fails across multiple timezones -- Key: TRINIDAD-1920 URL: https://issues.apache.org/jira/browse/TRINIDAD-1920 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 1.2.13-core Reporter: Yee-Wah Lee Priority: Minor Fix For: 2.0.0.3-core, 1.2.15-core Attachments: 12123_1920.diff, 12x_1920.diff, trin12_1920.diff This is a regression from TRINIDAD-1818 where the DateTimeRangeValidator was created with Date/ms. https://issues.apache.org/jira/browse/TRINIDAD-1818 Because the Javascript client is not able to correctly calculate timezone offsets for different timezones, it should take the min/max as a String and convert that into a Date. The converted value would have the same offset as the value, and validation would be all on objects with the same timezone offset. Fix is to revert to using Strings, but also pass the date as an ISO string when the converter pattern is insufficient. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1958) Client tr:numberConverter with type=currency incorrectly handles arabic locale for positive values
Client tr:numberConverter with type=currency incorrectly handles arabic
locale for positive values
Key: TRINIDAD-1958
URL: https://issues.apache.org/jira/browse/TRINIDAD-1958
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Affects Versions: 1.2.13-core
Reporter: Yee-Wah Lee
Priority: Minor
1. Use the following jspx, binding the value of the inputText to a positive
integer.
tr:inputText label=InputText Arabic value=#{clientValidation.integer}
autoSubmit=true
tr:convertNumber type=currency locale=ar_SA/
/tr:inputText
tr:outputText value=Value submitted is
#{clientValidation.integer}/
2. Run the jspx, it displays something like:
2ر.س. 0
3. Modify just the numerical portion of the text and tab off: Get an Incorrect
Format error
Enter a currency in the same format as this example: ر.س. 10,250
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1958) Client tr:numberConverter with type=currency incorrectly handles arabic locale for positive values
[
https://issues.apache.org/jira/browse/TRINIDAD-1958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12930301#action_12930301
]
Yee-Wah Lee commented on TRINIDAD-1958:
---
The locale files define the currency data using prefix and suffix for the
currency, e.g. in the localeElements_en_US.js defines
CurrencyElements:[\xa4, XXX, \xa4, , -\xa4, ],
which is interpreted as [Currency Symbol, Currency Code, Positive Prefix,
Positive Suffix, Negative Prefix, Negative Suffix]. See
Locale.js#_getCurrency*.
The following is currency data for some locales:
en_US:
positive prefix: $
positive suffix: , empty string
negative prefix: ($
negative suffix: )
For Hebrew (he_IL):
positive prefix: , empty string
positive suffix: \u05e9\x22\u05d7
negative prefix: -
negative suffix: \u05e9\x22\u05d7
Arabic (ar_SA), note the values for negative prefix and negative suffix
positive prefix: \u0631.\u0633.\u200f
positive suffix: , empty string
negative prefix: \u0631.\u0633.\u200f
negative suffix: -
The client number converter assumes the negative prefix is in the front,and
tests for that first. In the arabic case, the locale files define negative
prefix the same as positive prefix so it goes into the first clause which
additionally searches for the negative suffix. Failing to find that, it throws
a ParseException.
TrNumberFormat.prototype.stringToCurrency = function(numberString)
{
//is the string negative ?
var negP = numberString.indexOf(this._nPre);
if(negP != -1)
{
numberString = numberString.substr(this._nPre.length, numberString.length);
..
if(negS != -1)
{
// parse thev alue
}
else
{
throw new TrParseException(not able to parse number);
}
}
Client tr:numberConverter with type=currency incorrectly handles arabic
locale for positive values
Key: TRINIDAD-1958
URL: https://issues.apache.org/jira/browse/TRINIDAD-1958
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Affects Versions: 1.2.13-core
Reporter: Yee-Wah Lee
Priority: Minor
1. Use the following jspx, binding the value of the inputText to a positive
integer.
tr:inputText label=InputText Arabic value=#{clientValidation.integer}
autoSubmit=true
tr:convertNumber type=currency locale=ar_SA/
/tr:inputText
tr:outputText value=Value submitted is
#{clientValidation.integer}/
2. Run the jspx, it displays something like:
2ر.س. 0
3. Modify just the numerical portion of the text and tab off: Get an
Incorrect Format error
Enter a currency in the same format as this example: ر.س. 10,250
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1958) Client tr:numberConverter with type=currency incorrectly handles arabic locale for positive values
[
https://issues.apache.org/jira/browse/TRINIDAD-1958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12930308#action_12930308
]
Yee-Wah Lee commented on TRINIDAD-1958:
---
The CurrencyElements in the JS file is generated by maven-i18n-plugin which
uses DecimalFormatSymbols#getCurrencySymbol(), getCurrencyCode(), etc.
JSLocaleElementsGenerator.java#_getCurrencyData
DecimalFormat df = (DecimalFormat)
NumberFormat.getCurrencyInstance(targetLocale);
DecimalFormatSymbols decimalFormatSymbols = df.getDecimalFormatSymbols();
Object[] currencyData = new Object[6];
currencyData[0] = decimalFormatSymbols.getCurrencySymbol();
currencyData[1] = decimalFormatSymbols.getCurrency().getCurrencyCode();
currencyData[2] = df.getPositivePrefix();
currencyData[3] = df.getPositiveSuffix();
currencyData[4] = df.getNegativePrefix();
currencyData[5] = df.getNegativeSuffix();
..
Tried using native Arabic Windows box, and in the regional setting dialog, the
currency format is same as JDK's format value.
Client tr:numberConverter with type=currency incorrectly handles arabic
locale for positive values
Key: TRINIDAD-1958
URL: https://issues.apache.org/jira/browse/TRINIDAD-1958
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Affects Versions: 1.2.13-core
Reporter: Yee-Wah Lee
Priority: Minor
1. Use the following jspx, binding the value of the inputText to a positive
integer.
tr:inputText label=InputText Arabic value=#{clientValidation.integer}
autoSubmit=true
tr:convertNumber type=currency locale=ar_SA/
/tr:inputText
tr:outputText value=Value submitted is
#{clientValidation.integer}/
2. Run the jspx, it displays something like:
2ر.س. 0
3. Modify just the numerical portion of the text and tab off: Get an
Incorrect Format error
Enter a currency in the same format as this example: ر.س. 10,250
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (TRINIDAD-1958) Client tr:numberConverter with type=currency incorrectly handles arabic locale for positive values
[
https://issues.apache.org/jira/browse/TRINIDAD-1958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12930307#action_12930307
]
Yee-Wah Lee edited comment on TRINIDAD-1958 at 11/9/10 5:01 PM:
Need to confirm if the Arabic symbols for negative pre/suffix are indeed
correct.
That is, if I want to represent the value -9 in currency, this is correct:
en_US: ($9)
he_IL: -9 ??
ar_SA: 9 ?? -
where ?? are the currency symbols for the respective languages.
If the above is correct, although Hebrew and Arabic are both BiDi languages
they represent negative numbers differently (pre vs suffix) and the code would
indeed need to change.
was (Author: yeelee):
Need to confirm if the Arabic symbols for negative pre/suffix are indeed
correct.
That is, if I want to represent the value -9 in currency, this is correct:
en_US: ($9)
he_IL: -9 ??
ar_IW: 9 ?? -
where ?? are the currency symbols for the respective languages.
If the above is correct, although Hebrew and Arabic are both BiDi languages
they represent negative numbers differently (pre vs suffix) and the code would
indeed need to change.
Client tr:numberConverter with type=currency incorrectly handles arabic
locale for positive values
Key: TRINIDAD-1958
URL: https://issues.apache.org/jira/browse/TRINIDAD-1958
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Affects Versions: 1.2.13-core
Reporter: Yee-Wah Lee
Priority: Minor
1. Use the following jspx, binding the value of the inputText to a positive
integer.
tr:inputText label=InputText Arabic value=#{clientValidation.integer}
autoSubmit=true
tr:convertNumber type=currency locale=ar_SA/
/tr:inputText
tr:outputText value=Value submitted is
#{clientValidation.integer}/
2. Run the jspx, it displays something like:
2ر.س. 0
3. Modify just the numerical portion of the text and tab off: Get an
Incorrect Format error
Enter a currency in the same format as this example: ر.س. 10,250
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1958) Client tr:numberConverter with type=currency incorrectly handles arabic locale for positive values
[
https://issues.apache.org/jira/browse/TRINIDAD-1958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12930307#action_12930307
]
Yee-Wah Lee commented on TRINIDAD-1958:
---
Need to confirm if the Arabic symbols for negative pre/suffix are indeed
correct.
That is, if I want to represent the value -9 in currency, this is correct:
en_US: ($9)
he_IL: -9 ??
ar_IW: 9 ?? -
where ?? are the currency symbols for the respective languages.
If the above is correct, although Hebrew and Arabic are both BiDi languages
they represent negative numbers differently (pre vs suffix) and the code would
indeed need to change.
Client tr:numberConverter with type=currency incorrectly handles arabic
locale for positive values
Key: TRINIDAD-1958
URL: https://issues.apache.org/jira/browse/TRINIDAD-1958
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Affects Versions: 1.2.13-core
Reporter: Yee-Wah Lee
Priority: Minor
1. Use the following jspx, binding the value of the inputText to a positive
integer.
tr:inputText label=InputText Arabic value=#{clientValidation.integer}
autoSubmit=true
tr:convertNumber type=currency locale=ar_SA/
/tr:inputText
tr:outputText value=Value submitted is
#{clientValidation.integer}/
2. Run the jspx, it displays something like:
2ر.س. 0
3. Modify just the numerical portion of the text and tab off: Get an
Incorrect Format error
Enter a currency in the same format as this example: ر.س. 10,250
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1958) Client tr:numberConverter with type=currency incorrectly handles arabic locale for positive values
[
https://issues.apache.org/jira/browse/TRINIDAD-1958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12930357#action_12930357
]
Yee-Wah Lee commented on TRINIDAD-1958:
---
Thanks Hazem for the confirmation!
This bug is then a JDK issue, since we use JDK's DecimalFormatSymbols for
generating the currency data.
Client tr:numberConverter with type=currency incorrectly handles arabic
locale for positive values
Key: TRINIDAD-1958
URL: https://issues.apache.org/jira/browse/TRINIDAD-1958
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Affects Versions: 1.2.13-core
Reporter: Yee-Wah Lee
Priority: Minor
1. Use the following jspx, binding the value of the inputText to a positive
integer.
tr:inputText label=InputText Arabic value=#{clientValidation.integer}
autoSubmit=true
tr:convertNumber type=currency locale=ar_SA/
/tr:inputText
tr:outputText value=Value submitted is
#{clientValidation.integer}/
2. Run the jspx, it displays something like:
2ر.س. 0
3. Modify just the numerical portion of the text and tab off: Get an
Incorrect Format error
Enter a currency in the same format as this example: ر.س. 10,250
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1887) Javascript failure with tr:NumberConverter type=currency
[
https://issues.apache.org/jira/browse/TRINIDAD-1887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12920811#action_12920811
]
Yee-Wah Lee commented on TRINIDAD-1887:
---
With ar_sa locale, the curency symbols defined in locale.js are:
CurrencyElements:[\u0631.\u0633.\u200f, SAR, \u0631.\u0633.\u200f , ,
\u0631.\u0633.\u200f , -],
The error message when incrementing/decrementing is:
value, stepSize, min, and max must all be numbers. value: ر.س. 9, stepSize: 2,
min: 1, max: 100
Javascript failure with tr:NumberConverter type=currency
Key: TRINIDAD-1887
URL: https://issues.apache.org/jira/browse/TRINIDAD-1887
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Affects Versions: 1.2.13-core
Reporter: Yee-Wah Lee
Priority: Minor
1. Create an inputNumberSpinbox with type currency.
tr:inputNumberSpinbox label=Label 1 id=ins1
value=#{clientValidation.integer}
minimum=1 maximum=100 stepSize=2
tr:convertNumber type=currency/
/tr:inputNumberSpinbox
2. Run the demo. Notice the value contains generic currency symbol 78,57 ¤.
Press the up arrow to increment value. Get a message:
value, stepSize, min, and max must all be numbers. value: 78,57 ¤, stepSize:
1, min: 1, max: 2147483647
Tried for different locales - en, fr, ar
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-1920) DateTimeRangevalidator fails across multiple timezones
[ https://issues.apache.org/jira/browse/TRINIDAD-1920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yee-Wah Lee updated TRINIDAD-1920: -- Status: Patch Available (was: Open) DateTimeRangevalidator fails across multiple timezones -- Key: TRINIDAD-1920 URL: https://issues.apache.org/jira/browse/TRINIDAD-1920 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 1.2.13-core Reporter: Yee-Wah Lee Priority: Minor Attachments: 12123_1920.diff, trin12_1920.diff This is a regression from TRINIDAD-1818 where the DateTimeRangeValidator was created with Date/ms. https://issues.apache.org/jira/browse/TRINIDAD-1818 Because the Javascript client is not able to correctly calculate timezone offsets for different timezones, it should take the min/max as a String and convert that into a Date. The converted value would have the same offset as the value, and validation would be all on objects with the same timezone offset. Fix is to revert to using Strings, but also pass the date as an ISO string when the converter pattern is insufficient. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1931) Date-Time converter does not use 2DigitYearStart for parsing
Date-Time converter does not use 2DigitYearStart for parsing Key: TRINIDAD-1931 URL: https://issues.apache.org/jira/browse/TRINIDAD-1931 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 1.2.13-core Reporter: Yee-Wah Lee According to the doc: http://myfaces.apache.org/trinidad/devguide/configuration.html#trinidad-config.xml The two-digit-year-start element defines the year offset that should be used for parsing years with only two digits. If it is not set, it is defaulted to year 1950. This value is used by org.apache.myfaces.trinidad.converter.DateTimeConverter while converting strings to Date. This property may also be explicitly configured with an EL expression that returns Integer object if needed or can be directly harcoded to a integer value. This is not apparently used by the DateTimeConverter in parsing, probably a regression from TRINIDAD-208. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1920) DateTimeRangevalidator fails across multiple timezones
DateTimeRangevalidator fails across multiple timezones -- Key: TRINIDAD-1920 URL: https://issues.apache.org/jira/browse/TRINIDAD-1920 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 1.2.13-core Reporter: Yee-Wah Lee Priority: Minor This is a regression from TRINIDAD-1818 where the DateTimeRangeValidator was created with Date/ms. https://issues.apache.org/jira/browse/TRINIDAD-1818 Because the Javascript client is not able to correctly calculate timezone offsets for different timezones, it should take the min/max as a String and convert that into a Date. The converted value would have the same offset as the value, and validation would be all on objects with the same timezone offset. Fix is to revert to using Strings, but also pass the date as an ISO string when the converter pattern is insufficient. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1818) TrDateTimeRangeValidator should validate using date object, not date string
[ https://issues.apache.org/jira/browse/TRINIDAD-1818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12913275#action_12913275 ] Yee-Wah Lee commented on TRINIDAD-1818: --- Created TRINIDAD-1920 to track changes for fixing this and TRINIDAD-748 since this has been committed. TrDateTimeRangeValidator should validate using date object, not date string --- Key: TRINIDAD-1818 URL: https://issues.apache.org/jira/browse/TRINIDAD-1818 Project: MyFaces Trinidad Issue Type: Bug Components: Components Reporter: Cale Scholl Priority: Minor Attachments: TrDateTimeRangeValidator_1.2.12.3.patch, TrDateTimeRangeValidator_2_2.0.0.3.1.patch, TrDateTimeRangeValidator_2_trunk.patch, TrDateTimeRangeValidator_3_2.0.0.3.1.patch, TrDateTimeRangeValidator_3_trunk.patch TrDateTimeRangeValidator converts date strings to date objects in order to do validation. Just use the date objects directly, if available. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1887) Javascript failure with tr:NumberConverter type=currency
Javascript failure with tr:NumberConverter type=currency
Key: TRINIDAD-1887
URL: https://issues.apache.org/jira/browse/TRINIDAD-1887
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Affects Versions: 1.2.13-core
Reporter: Yee-Wah Lee
Priority: Minor
1. Create an inputNumberSpinbox with type currency.
tr:inputNumberSpinbox label=Label 1 id=ins1
value=#{clientValidation.integer}
minimum=1 maximum=100 stepSize=2
tr:convertNumber type=currency/
/tr:inputNumberSpinbox
2. Run the demo. Notice the value contains generic currency symbol 78,57 ¤.
Press the up arrow to increment value. Get a message:
value, stepSize, min, and max must all be numbers. value: 78,57 ¤, stepSize: 1,
min: 1, max: 2147483647
Tried for different locales - en, fr, ar
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1887) Javascript failure with tr:NumberConverter type=currency
[
https://issues.apache.org/jira/browse/TRINIDAD-1887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12900065#action_12900065
]
Yee-Wah Lee commented on TRINIDAD-1887:
---
Before closing this issue, please test ar locale. The ar currency code,
\u0631.\u0633.\u200f, contains . which may be interpreted as decimal
separator.
Also, I have checked that the faces-config contains supported-locale for each
locale I was testing.
Javascript failure with tr:NumberConverter type=currency
Key: TRINIDAD-1887
URL: https://issues.apache.org/jira/browse/TRINIDAD-1887
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Affects Versions: 1.2.13-core
Reporter: Yee-Wah Lee
Priority: Minor
1. Create an inputNumberSpinbox with type currency.
tr:inputNumberSpinbox label=Label 1 id=ins1
value=#{clientValidation.integer}
minimum=1 maximum=100 stepSize=2
tr:convertNumber type=currency/
/tr:inputNumberSpinbox
2. Run the demo. Notice the value contains generic currency symbol 78,57 ¤.
Press the up arrow to increment value. Get a message:
value, stepSize, min, and max must all be numbers. value: 78,57 ¤, stepSize:
1, min: 1, max: 2147483647
Tried for different locales - en, fr, ar
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1818) TrDateTimeRangeValidator should validate using date object, not date string
[ https://issues.apache.org/jira/browse/TRINIDAD-1818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12897976#action_12897976 ] Yee-Wah Lee commented on TRINIDAD-1818: --- This regresses TRINIDAD-748 because the validator will not consistently validate across timezones if dates were used. TrDateTimeRangeValidator should validate using date object, not date string --- Key: TRINIDAD-1818 URL: https://issues.apache.org/jira/browse/TRINIDAD-1818 Project: MyFaces Trinidad Issue Type: Bug Components: Components Reporter: Cale Scholl Priority: Minor Attachments: TrDateTimeRangeValidator_1.2.12.3.patch, TrDateTimeRangeValidator_2_2.0.0.3.1.patch, TrDateTimeRangeValidator_2_trunk.patch, TrDateTimeRangeValidator_3_2.0.0.3.1.patch, TrDateTimeRangeValidator_3_trunk.patch TrDateTimeRangeValidator converts date strings to date objects in order to do validation. Just use the date objects directly, if available. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1859) Documentation states incorrect default for convertDateTime's 'timeZone' attribute
Documentation states incorrect default for convertDateTime's 'timeZone' attribute - Key: TRINIDAD-1859 URL: https://issues.apache.org/jira/browse/TRINIDAD-1859 Project: MyFaces Trinidad Issue Type: Bug Components: Documentation Affects Versions: 1.2.13-core Reporter: Yee-Wah Lee Priority: Minor tr:convertDateTime has incorrect documentation for timeZone attribute. It currently states : Timezone can be set per web-app in trinidad-config.xml configuration file. If timeZone is not set on the converter, then timezone will be defaulted to the value set in trinidad-config.xml configuration file. If it is not set in the configuration file, then it will be defaulted to GMT. However, the default (when not set on converter or trinidad-config.xml) is actually TimeZone.getDefault(). See RequestContextImpl.getTimeZone() -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-1859) Documentation states incorrect default for convertDateTime's 'timeZone' attribute
[ https://issues.apache.org/jira/browse/TRINIDAD-1859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yee-Wah Lee updated TRINIDAD-1859: -- Status: Patch Available (was: Open) Documentation states incorrect default for convertDateTime's 'timeZone' attribute - Key: TRINIDAD-1859 URL: https://issues.apache.org/jira/browse/TRINIDAD-1859 Project: MyFaces Trinidad Issue Type: Bug Components: Documentation Affects Versions: 1.2.13-core Reporter: Yee-Wah Lee Priority: Minor Attachments: trin12_1859.diff tr:convertDateTime has incorrect documentation for timeZone attribute. It currently states : Timezone can be set per web-app in trinidad-config.xml configuration file. If timeZone is not set on the converter, then timezone will be defaulted to the value set in trinidad-config.xml configuration file. If it is not set in the configuration file, then it will be defaulted to GMT. However, the default (when not set on converter or trinidad-config.xml) is actually TimeZone.getDefault(). See RequestContextImpl.getTimeZone() -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1734) Facelets: need metarule to convert String- Timezone for date converter
Facelets: need metarule to convert String- Timezone for date converter
Key: TRINIDAD-1734
URL: https://issues.apache.org/jira/browse/TRINIDAD-1734
Project: MyFaces Trinidad
Issue Type: Bug
Components: Facelets
Affects Versions: 2.0.0.2-core
Reporter: Yee-Wah Lee
Priority: Minor
1. Modify the inputDate demo to specify timezone as a string on the converter,
e.g.
tr:inputDate id=mdf8 value=#{date.date5} label=attached
converter with locale ja
tr:convertDateTime locale=ja type=date dateStyle=full
timeZone=America/New_York/
/tr:inputDate
2. Run the page with facelets enabled. Get the following runtime error:
java.lang.IllegalArgumentException: Cannot convert America/New_York of type
class java.lang.String to class java.util.TimeZone
at com.sun.el.lang.ELSupport.coerceToType(ELSupport.java:381)
at
com.sun.el.ExpressionFactoryImpl.coerceToType(ExpressionFactoryImpl.java:66)
at
com.sun.faces.facelets.tag.BeanPropertyTagRule$LiteralPropertyMetadata.applyMetadata(BeanPropertyTagRule.java:81)
at
com.sun.faces.facelets.tag.MetadataImpl.applyMetadata(MetadataImpl.java:74)
at
javax.faces.view.facelets.MetaTagHandler.setAttributes(MetaTagHandler.java:122)
at
javax.faces.view.facelets.DelegatingMetaTagHandler.setAttributes(DelegatingMetaTagHandler.java:96)
at
com.sun.faces.facelets.tag.jsf.ConverterTagHandlerDelegateImpl.applyAttachedObject(ConverterTagHandlerDelegateImpl.java:126)
at
javax.faces.view.facelets.FaceletsAttachedObjectHandler.applyAttachedObject(FaceletsAttachedObjectHandler.java:91)
at
com.sun.faces.facelets.tag.jsf.ConverterTagHandlerDelegateImpl.apply(ConverterTagHandlerDelegateImpl.java:73)
at
javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:114)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-1734) Facelets: need metarule to convert String- Timezone for date converter
[
https://issues.apache.org/jira/browse/TRINIDAD-1734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yee-Wah Lee updated TRINIDAD-1734:
--
Status: Patch Available (was: Open)
Facelets: need metarule to convert String- Timezone for date converter
Key: TRINIDAD-1734
URL: https://issues.apache.org/jira/browse/TRINIDAD-1734
Project: MyFaces Trinidad
Issue Type: Bug
Components: Facelets
Affects Versions: 2.0.0.2-core
Reporter: Yee-Wah Lee
Priority: Minor
Attachments: trin2_1734.diff
1. Modify the inputDate demo to specify timezone as a string on the
converter, e.g.
tr:inputDate id=mdf8 value=#{date.date5} label=attached
converter with locale ja
tr:convertDateTime locale=ja type=date dateStyle=full
timeZone=America/New_York/
/tr:inputDate
2. Run the page with facelets enabled. Get the following runtime error:
java.lang.IllegalArgumentException: Cannot convert America/New_York of type
class java.lang.String to class java.util.TimeZone
at com.sun.el.lang.ELSupport.coerceToType(ELSupport.java:381)
at
com.sun.el.ExpressionFactoryImpl.coerceToType(ExpressionFactoryImpl.java:66)
at
com.sun.faces.facelets.tag.BeanPropertyTagRule$LiteralPropertyMetadata.applyMetadata(BeanPropertyTagRule.java:81)
at
com.sun.faces.facelets.tag.MetadataImpl.applyMetadata(MetadataImpl.java:74)
at
javax.faces.view.facelets.MetaTagHandler.setAttributes(MetaTagHandler.java:122)
at
javax.faces.view.facelets.DelegatingMetaTagHandler.setAttributes(DelegatingMetaTagHandler.java:96)
at
com.sun.faces.facelets.tag.jsf.ConverterTagHandlerDelegateImpl.applyAttachedObject(ConverterTagHandlerDelegateImpl.java:126)
at
javax.faces.view.facelets.FaceletsAttachedObjectHandler.applyAttachedObject(FaceletsAttachedObjectHandler.java:91)
at
com.sun.faces.facelets.tag.jsf.ConverterTagHandlerDelegateImpl.apply(ConverterTagHandlerDelegateImpl.java:73)
at
javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:114)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1550) convertDateTime handles type=date incorrectly
[
https://issues.apache.org/jira/browse/TRINIDAD-1550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12803018#action_12803018
]
Yee-Wah Lee commented on TRINIDAD-1550:
---
Agreed that in the case when type=time, the Trinidad converter does generate
value change because it doesn't try to preserve the date values.This is
inconsistent with type=date.
One workaround I can think of is to zero out the hour, minute, second,
millisecond fields of the dateCal. That should work regardless which renderkit
is used.
Or, try to avoid picking up the trinidad date-time converter which may be only
available in JSF 2.0 since the Trinidad framework registers its
datetimeConverter as the default (so that f:convertDateTime picks it up).
convertDateTime handles type=date incorrectly
---
Key: TRINIDAD-1550
URL: https://issues.apache.org/jira/browse/TRINIDAD-1550
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Affects Versions: 1.2.10-core
Environment: Linux 64-bit, Java 1.5.0_11
Reporter: Eric Price
Priority: Minor
I have a backing bean that contains two HtmlInputText components. One stores
the date part of a Date, the other stores the time part of a Date. When
the user enters the information, the date and time are combined to form
the actual Date.
The bean has the following declarations:
public class DateTestBean {
private HtmlInputText dateInput = null;
private HtmlInputText timeInput = null;
private Date date = null;
private Date time = null;
public DateTestBean() {
dateInput = new HtmlInputText();
timeInput = new HtmlInputText();
date = Calendar.getInstance( TimeZone.getTimeZone( GMT ) );
time = (Date)date.clone();
}
}
For my sample program, I have a button on the jsp that calls the action
method setDateAction() to update the date/time values with current values.
That method is shown below:
public String setDateAction() {
Calendar dateCal = Calendar.getInstance( TimeZone.getTimeZone( GMT ) );
Calendar timeCal = (Calendar)dateCal.clone();
dateInput.setValue( dateCal.getTime() );
timeInput.setValue( timeCal.getTime() );
date = dateCal.getTime();
time = timeCal.getTime();
return success;
}
There is a corresponding action method associated with a submit button on the
jsp that prints the date/time values when the page is submitted.
public String displayDateAction() {
Object valObj = this.dateInput.getValue();
if (valObj instanceof Date) {
System.out.println( date= + formatDate( (Date)valObj ) );
}
valObj = this.timeInput.getValue();
if (valObj instanceof Date) {
System.out.println( time= + formatDate( (Date)valObj ) );
}
}
Here is the code snipit from the jsp:
t:panelGrid columns=2
t:inputText binding=#{dateTestBean.dateInput} size=10 maxlength=10
immediate=true value=#{dateTestBean.date} title=-MM-dd
id=dateInput
f:convertDateTime type=date pattern=-MM-dd/
/t:inputText
t:inputText binding=#{dateTestBean.timeInput} size=8 maxlength=8
immediate=true value=#{dateTestBean.time} title=HH:mm:ss
id=timeUpStartTimeInput
f:convertDateTime type=time pattern=HH:mm:ss/
/t:inputText
/t:panelGrid
t:panelGrid columns=2
t:commandButton value=Set Date action=#{dateTestBean.setDateAction}/
t:commandButton value=Show Date
action=#{dateTestBean.displayDateAction}/
/t:panelGrid
When I submit the page, I see different values for the date and time
depending on whether or not I'm using the trinidad rendering kit.
When the page loads the date and time fields are set to the correct date
and time values. When the page is submitted, I see the following:
Under MyFaces 1.1.4 (or JSF 1.1), Java 1.5, tomahawk 1.1.3 and assuming the
date was 12:20:32 on Aug 4th 2009, I get:
date = '2009-08-04 00:00:00'
time= '1970-01-01 12:20:32'
Similarly, under MyFaces 1.2.6 (or JSF 1.2), Java 1.5, tomahawk 12-1.1.8 and
assuming the date was 12:20:32 on Aug 4th 2009, I get:
date = '2009-08-04 00:00:00'
time= '1970-01-01 12:20:32'
So if I combine the two values when the page is submitted, I end up with
'2009-08-04 12:20:32', which is the correct submit date/time.
Under MyFaces 1.2.6 (or JSF 1.2), Java 1.5, trinidad-1.2.10, and assuming the
same date/time values are set, I get:
date= '2009-08-04 12:20:32'
time= '1970-01-01 12:20:32'
So the convertDateTime with type=date is not zero-ing out the time field
values, but the one with type=time is zero-ing out the date field values.
I've done a lot of testing and originally thought the problem with with
myFaces 1.2. But I eventually
[jira] Created: (TRINIDAD-1657) Client date time converter does not properly handle quote escaping
Client date time converter does not properly handle quote escaping -- Key: TRINIDAD-1657 URL: https://issues.apache.org/jira/browse/TRINIDAD-1657 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 1.2.12-core Reporter: Yee-Wah Lee Priority: Minor 1. Create a test page with the following: tr:inputDate label=Label 1 id=id1 tr:convertDateTime type=both dateStyle=long timeStyle=full/ /tr:inputDate 2. Add the following to faces-config.xml supported-localeen_GB/supported-locale 3. Run the page with browser language/country set to EN_GB. It should display some initial value like 22-Nov-2009 23:33:34 o' clock 4. Open the date picker, and pick a value. Notice the new value appears something like 22-Nov-2009 23:33:34 oclock, the o'clock has lost its single quote. 5. Try to submit, it gives an error about invalid format. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1634) tr:convertDateTime error handling can be improved to distinguish invalid date from invalid date format
[
https://issues.apache.org/jira/browse/TRINIDAD-1634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12782560#action_12782560
]
Yee-Wah Lee commented on TRINIDAD-1634:
---
Patch does not address the case where client-validation is disabled in
trinidad-config.xml. In DateTimeConverter#_parse(), both string inputs
'11/35/09' and '11/aa/09' throw a ParseException with parseMessage=Unparseable
date: %0.
DateFormat fmt = getDateFormat(context, pattern, true, null);
try
{
return fmt.parse(value);
} catch (ConverterException ce)
{
throw ce;
}
catch (ParseException pe)
{
Object[] params = _getPlaceHolderParameters(context, component, value);
throw new ConverterException(getParseErrorMessage(context, component,
pattern, params),
pe);
}
tr:convertDateTime error handling can be improved to distinguish invalid date
from invalid date format
--
Key: TRINIDAD-1634
URL: https://issues.apache.org/jira/browse/TRINIDAD-1634
Project: MyFaces Trinidad
Issue Type: Improvement
Components: Components
Affects Versions: 1.2.12-core
Reporter: Yee-Wah Lee
Priority: Minor
Attachments: trin12_1634.diff
1. Run the inputDate demo
http://www.irian.at/trinidad-demo/faces/components/inputDate.jspx
2. On the top inputDate, type in a non-existing date, e.g. 2/29/2009 and
click the Submit button.
3. Error message returned is:
Enter a date in the same format as this example: 11/29/1998
The date is actually in a valid format, so this is to see if the error
handling can distinguish the invalid format case from the invalid date case.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1643) tr:convertDateTime server error handling can be improved to distinguish invalid date from invalid date format
tr:convertDateTime server error handling can be improved to distinguish invalid date from invalid date format - Key: TRINIDAD-1643 URL: https://issues.apache.org/jira/browse/TRINIDAD-1643 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 1.2.12-core Reporter: Yee-Wah Lee Priority: Minor This is filed from TRINIDAD-1634. The patch therein does not work if client-validation is disabled in trinidad-config.xml. This is to track if a fix can be made to distinguish the types of parseException when the string is '11/aa/09' or '11/35/09'. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1634) tr:convertDateTime error handling can be improved to distinguish invalid date from invalid date format
[ https://issues.apache.org/jira/browse/TRINIDAD-1634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12782572#action_12782572 ] Yee-Wah Lee commented on TRINIDAD-1634: --- Filed TRINIDAD-1643 to track the server fix. https://issues.apache.org/jira/browse/TRINIDAD-1643 tr:convertDateTime error handling can be improved to distinguish invalid date from invalid date format -- Key: TRINIDAD-1634 URL: https://issues.apache.org/jira/browse/TRINIDAD-1634 Project: MyFaces Trinidad Issue Type: Improvement Components: Components Affects Versions: 1.2.12-core Reporter: Yee-Wah Lee Priority: Minor Attachments: trin12_1634.diff 1. Run the inputDate demo http://www.irian.at/trinidad-demo/faces/components/inputDate.jspx 2. On the top inputDate, type in a non-existing date, e.g. 2/29/2009 and click the Submit button. 3. Error message returned is: Enter a date in the same format as this example: 11/29/1998 The date is actually in a valid format, so this is to see if the error handling can distinguish the invalid format case from the invalid date case. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-1634) tr:convertDateTime error handling can be improved to distinguish invalid date from invalid date format
[ https://issues.apache.org/jira/browse/TRINIDAD-1634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yee-Wah Lee updated TRINIDAD-1634: -- Status: Patch Available (was: Open) tr:convertDateTime error handling can be improved to distinguish invalid date from invalid date format -- Key: TRINIDAD-1634 URL: https://issues.apache.org/jira/browse/TRINIDAD-1634 Project: MyFaces Trinidad Issue Type: Improvement Components: Components Affects Versions: 1.2.12-core Reporter: Yee-Wah Lee Priority: Minor 1. Run the inputDate demo http://www.irian.at/trinidad-demo/faces/components/inputDate.jspx 2. On the top inputDate, type in a non-existing date, e.g. 2/29/2009 and click the Submit button. 3. Error message returned is: Enter a date in the same format as this example: 11/29/1998 The date is actually in a valid format, so this is to see if the error handling can distinguish the invalid format case from the invalid date case. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-1634) tr:convertDateTime error handling can be improved to distinguish invalid date from invalid date format
[ https://issues.apache.org/jira/browse/TRINIDAD-1634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yee-Wah Lee updated TRINIDAD-1634: -- Status: Open (was: Patch Available) tr:convertDateTime error handling can be improved to distinguish invalid date from invalid date format -- Key: TRINIDAD-1634 URL: https://issues.apache.org/jira/browse/TRINIDAD-1634 Project: MyFaces Trinidad Issue Type: Improvement Components: Components Affects Versions: 1.2.12-core Reporter: Yee-Wah Lee Priority: Minor 1. Run the inputDate demo http://www.irian.at/trinidad-demo/faces/components/inputDate.jspx 2. On the top inputDate, type in a non-existing date, e.g. 2/29/2009 and click the Submit button. 3. Error message returned is: Enter a date in the same format as this example: 11/29/1998 The date is actually in a valid format, so this is to see if the error handling can distinguish the invalid format case from the invalid date case. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-1634) tr:convertDateTime error handling can be improved to distinguish invalid date from invalid date format
[ https://issues.apache.org/jira/browse/TRINIDAD-1634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yee-Wah Lee updated TRINIDAD-1634: -- Status: Patch Available (was: Open) tr:convertDateTime error handling can be improved to distinguish invalid date from invalid date format -- Key: TRINIDAD-1634 URL: https://issues.apache.org/jira/browse/TRINIDAD-1634 Project: MyFaces Trinidad Issue Type: Improvement Components: Components Affects Versions: 1.2.12-core Reporter: Yee-Wah Lee Priority: Minor Attachments: trin12_1634.diff 1. Run the inputDate demo http://www.irian.at/trinidad-demo/faces/components/inputDate.jspx 2. On the top inputDate, type in a non-existing date, e.g. 2/29/2009 and click the Submit button. 3. Error message returned is: Enter a date in the same format as this example: 11/29/1998 The date is actually in a valid format, so this is to see if the error handling can distinguish the invalid format case from the invalid date case. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1634) tr:convertDateTime error handling can be improved to distinguish invalid date from invalid date format
tr:convertDateTime error handling can be improved to distinguish invalid date from invalid date format -- Key: TRINIDAD-1634 URL: https://issues.apache.org/jira/browse/TRINIDAD-1634 Project: MyFaces Trinidad Issue Type: Improvement Components: Components Affects Versions: 1.2.12-core Reporter: Yee-Wah Lee Priority: Minor 1. Run the inputDate demo http://www.irian.at/trinidad-demo/faces/components/inputDate.jspx 2. On the top inputDate, type in a non-existing date, e.g. 2/29/2009 and click the Submit button. 3. Error message returned is: Enter a date in the same format as this example: 11/29/1998 The date is actually in a valid format, so this is to see if the error handling can distinguish the invalid format case from the invalid date case. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-1541) Image tooltips do not display in IE8
[ https://issues.apache.org/jira/browse/TRINIDAD-1541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yee-Wah Lee updated TRINIDAD-1541: -- Status: Patch Available (was: Open) Image tooltips do not display in IE8 Key: TRINIDAD-1541 URL: https://issues.apache.org/jira/browse/TRINIDAD-1541 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 1.2.11-core Environment: Browser: Internet Explorer 8, running in standard (not Compatibility View mode) Reporter: Yee-Wah Lee Priority: Trivial Attachments: trin12_1541.diff 1. Go to the chooseColor demo: http://www.irian.at/trinidad-demo/faces/components/chooseColor.jspx 2. Hover over one of the swatches in the table. In Firefox: a tooltip will appear with the #rgb value of the color In IE8, standard (turn off compatibility view mode) : no tooltip appears -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1550) convertDateTime handles type=date incorrectly
[
https://issues.apache.org/jira/browse/TRINIDAD-1550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12742888#action_12742888
]
Yee-Wah Lee commented on TRINIDAD-1550:
---
I think you are running into this portion of the code in trinidad-api
DateTimeConverter.java
/**
* Fill in the time portion of the new date with the time from the previous
* date value if the converter displays only date. For now, we are not
* bothered about filling all the missing parts of the pattern. But in
* future we would consider that.
*/
private void _fillTimePortion(
...
// convert the previous date value wrt client's timeZone
Calendar prevCal = Calendar.getInstance(timeZone);
prevCal.setTime(prevDate);
// convert the new date value wrt client's timeZone
Calendar newCal = Calendar.getInstance(timeZone);
newCal.setTime(newDate);
// extract all the missing time portions from the previous date value
// and set it to the new date value.
if (fillMilliSeconds)
{
newCal.set(Calendar.MILLISECOND, prevCal.get(Calendar.MILLISECOND));
}
if (fillSeconds)
{
newCal.set(Calendar.SECOND, prevCal.get(Calendar.SECOND));
}
..
If I am correct, the values that are being filled in (12:20:32) would vary each
time you run the application.
The scenario the code addresses is that the underlying Date has some
information (values for hour/min/sec/ms) but the converter is set to show date
only. If the user doesn't change anything and submits the page, if the
converter zeroed out the time portions, it would generate a value change even
though the user didn't explicitly change anything. The code is trying to avoid
the value change.
convertDateTime handles type=date incorrectly
---
Key: TRINIDAD-1550
URL: https://issues.apache.org/jira/browse/TRINIDAD-1550
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Affects Versions: 1.2.10-core
Environment: Linux 64-bit, Java 1.5.0_11
Reporter: Eric Price
Priority: Minor
I have a backing bean that contains two HtmlInputText components. One stores
the date part of a Date, the other stores the time part of a Date. When
the user enters the information, the date and time are combined to form
the actual Date.
The bean has the following declarations:
public class DateTestBean {
private HtmlInputText dateInput = null;
private HtmlInputText timeInput = null;
private Date date = null;
private Date time = null;
public DateTestBean() {
dateInput = new HtmlInputText();
timeInput = new HtmlInputText();
date = Calendar.getInstance( TimeZone.getTimeZone( GMT ) );
time = (Date)date.clone();
}
}
For my sample program, I have a button on the jsp that calls the action
method setDateAction() to update the date/time values with current values.
That method is shown below:
public String setDateAction() {
Calendar dateCal = Calendar.getInstance( TimeZone.getTimeZone( GMT ) );
Calendar timeCal = (Calendar)dateCal.clone();
dateInput.setValue( dateCal.getTime() );
timeInput.setValue( timeCal.getTime() );
date = dateCal.getTime();
time = timeCal.getTime();
return success;
}
There is a corresponding action method associated with a submit button on the
jsp that prints the date/time values when the page is submitted.
public String displayDateAction() {
Object valObj = this.dateInput.getValue();
if (valObj instanceof Date) {
System.out.println( date= + formatDate( (Date)valObj ) );
}
valObj = this.timeInput.getValue();
if (valObj instanceof Date) {
System.out.println( time= + formatDate( (Date)valObj ) );
}
}
Here is the code snipit from the jsp:
t:panelGrid columns=2
t:inputText binding=#{dateTestBean.dateInput} size=10 maxlength=10
immediate=true value=#{dateTestBean.date} title=-MM-dd
id=dateInput
f:convertDateTime type=date pattern=-MM-dd/
/t:inputText
t:inputText binding=#{dateTestBean.timeInput} size=8 maxlength=8
immediate=true value=#{dateTestBean.time} title=HH:mm:ss
id=timeUpStartTimeInput
f:convertDateTime type=time pattern=HH:mm:ss/
/t:inputText
/t:panelGrid
t:panelGrid columns=2
t:commandButton value=Set Date action=#{dateTestBean.setDateAction}/
t:commandButton value=Show Date
action=#{dateTestBean.displayDateAction}/
/t:panelGrid
When I submit the page, I see different values for the date and time
depending on whether or not I'm using the trinidad rendering kit.
When the page loads the date and time fields are set to the correct date
and time values. When the page is submitted, I
[jira] Commented: (TRINIDAD-1541) Image tooltips do not display in IE8
[ https://issues.apache.org/jira/browse/TRINIDAD-1541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12739029#action_12739029 ] Yee-Wah Lee commented on TRINIDAD-1541: --- The code which decides to generate alt vs title is in Trinidad, OutputUtils#renderAltAndTooltipForImage() checks the agent's capabilities. Image tooltips do not display in IE8 Key: TRINIDAD-1541 URL: https://issues.apache.org/jira/browse/TRINIDAD-1541 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 1.2.11-core Environment: Browser: Internet Explorer 8, running in standard (not Compatibility View mode) Reporter: Yee-Wah Lee Priority: Trivial 1. Go to the chooseColor demo: http://www.irian.at/trinidad-demo/faces/components/chooseColor.jspx 2. Hover over one of the swatches in the table. In Firefox: a tooltip will appear with the #rgb value of the color In IE8, standard (turn off compatibility view mode) : no tooltip appears -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1541) Image tooltips do not display in IE8
Image tooltips do not display in IE8 Key: TRINIDAD-1541 URL: https://issues.apache.org/jira/browse/TRINIDAD-1541 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 1.2.11-core Environment: Browser: Internet Explorer 8, running in standard (not Compatibility View mode) Reporter: Yee-Wah Lee Priority: Trivial 1. Go to the chooseColor demo: http://www.irian.at/trinidad-demo/faces/components/chooseColor.jspx 2. Hover over one of the swatches in the table. In Firefox: a tooltip will appear with the #rgb value of the color In IE8, standard (turn off compatibility view mode) : no tooltip appears -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1541) Image tooltips do not display in IE8
[ https://issues.apache.org/jira/browse/TRINIDAD-1541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12737262#action_12737262 ] Yee-Wah Lee commented on TRINIDAD-1541: --- Comparing the FF vs IE output, it seems that FF uses title attribute and IE uses alt attribute for tooltip. FF: img title=#CC66CC .. IE: img alt=#CC66CC ... However, in IE8 Release notes, alt is no longer used for tooltip. See section Accessibility and ARIA in this page: http://msdn.microsoft.com/en-us/library/cc288472(VS.85).aspx#access The alt attribute is no longer displayed as the image tooltip when the browser is running in IE8 mode. Instead, the target of the longDesc attribute is used as the tooltip if present; otherwise, the title is displayed. The alt attribute is still used as the Microsoft Active Accessibility name, and the title attribute is used as the fallback name only if alt is not present. Image tooltips do not display in IE8 Key: TRINIDAD-1541 URL: https://issues.apache.org/jira/browse/TRINIDAD-1541 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 1.2.11-core Environment: Browser: Internet Explorer 8, running in standard (not Compatibility View mode) Reporter: Yee-Wah Lee Priority: Trivial 1. Go to the chooseColor demo: http://www.irian.at/trinidad-demo/faces/components/chooseColor.jspx 2. Hover over one of the swatches in the table. In Firefox: a tooltip will appear with the #rgb value of the color In IE8, standard (turn off compatibility view mode) : no tooltip appears -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-1512) ConvertDateTime uses static GMT+x string for timezone display, doesn't update for daylight savings
[
https://issues.apache.org/jira/browse/TRINIDAD-1512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yee-Wah Lee updated TRINIDAD-1512:
--
Status: Patch Available (was: Open)
ConvertDateTime uses static GMT+x string for timezone display, doesn't update
for daylight savings
--
Key: TRINIDAD-1512
URL: https://issues.apache.org/jira/browse/TRINIDAD-1512
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Affects Versions: 1.2.11-core
Reporter: Yee-Wah Lee
Priority: Minor
Attachments: branch12114_1512.diff, trin12_1512.diff
1. Create a jsp that uses tr:convertDateTime to display timezone, e.g.
af:outputText value=#{demoInput.date}
af:convertDateTime type=both timeStyle=full
timeZone=America/New_York/
/af:outputText
where demoInput.date returns the current date, e.g. June 17 09, 1:00 PM
2. Run the jsp. For June 17 09 the timezone is actually EDT (GMT - 4).
Instead it displays as EST
6/17/2009 1:00:00 PM GMT-05:00
If using the JSF standard DateTimeConverter, the output is:
Jun 17, 2009 1:00:00 PM EDT
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1512) ConvertDateTime uses static GMT+x string for timezone display, doesn't update for daylight savings
[
https://issues.apache.org/jira/browse/TRINIDAD-1512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12733899#action_12733899
]
Yee-Wah Lee commented on TRINIDAD-1512:
---
Sent an email out to dev mailing list, discussing if this is a JDK issue.
Excerpting the relevant code here:
1) DateTimeConverter.java#getFormattingTimeZone(TimeZone tZone)
This effectively creates a timezone with customized id. TimeZone zone =
(TimeZone) tZone.clone();
// set the id as GMT Sign Hours : Minutes
StringBuilder zoneId = new StringBuilder(9);
int rawOffset = zone.getRawOffset();
.. code to calculate and append GMT ± hours:mins
zone.setID(zoneId.toString());
return zone;
2) JDK 1.5: SimpleDateFormat#subFormat()
The 1.5 format code would look up a zone info file using the date's offset and
daylight savings.
case 17: // 'z' - ZONE_OFFSET
int zoneIndex =
formatData.getZoneIndex(calendar.getTimeZone().getID());
if (zoneIndex == -1) {
value = calendar.get(Calendar.ZONE_OFFSET) +
calendar.get(Calendar.DST_OFFSET);
buffer.append(ZoneInfoFile.toCustomID(value));
-Uses this code path
}
3) JDK 6: SimpleDateFormat#subFormat()
The 1.6 code now checks the DateFormatSymbols.locale and isZoneStringsSet(). By
default, the locale would be null and zoneStringsSet = false unless user
overrides either.It then calls TimeZone.getDisplayName() instead of checking
the zoneInfoFile.
case 17: // 'z' - ZONE_OFFSET
if (formatData.locale == null || formatData.isZoneStringsSet) {
..
// same as 1.5, looks up zone info file
String[][] zoneStrings = formatData.getZoneStringsWrapper();
buffer.append(zoneStrings[zoneIndex][index]);
} else {
TimeZone tz = calendar.getTimeZone();
boolean daylight = (calendar.get(Calendar.DST_OFFSET) != 0);
int tzstyle = (count 4 ? TimeZone.SHORT : TimeZone.LONG);
buffer.append(tz.getDisplayName(daylight, tzstyle,
formatData.locale)); Uses this code path
}...
4) JDK 1.5/6: TimeZone.getDisplayName()
This method is the same in both JDKs, but only called in JDK 6 case. If the ID
is customized (GMT ±x), it simply returns that.
String id = getID();
String[] names = getDisplayNames(id, locale);
if (names == null) {
if (id.startsWith(GMT)) {
char sign = id.charAt(3);
if (sign == '+' || sign == '-') {
return id;
Therefore, the display name for the Converter's timezone in JDK 6 is fixed as
its ID (GMT+/-rawOffset).
ConvertDateTime uses static GMT+x string for timezone display, doesn't update
for daylight savings
--
Key: TRINIDAD-1512
URL: https://issues.apache.org/jira/browse/TRINIDAD-1512
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Affects Versions: 1.2.11-core
Reporter: Yee-Wah Lee
Priority: Minor
1. Create a jsp that uses tr:convertDateTime to display timezone, e.g.
af:outputText value=#{demoInput.date}
af:convertDateTime type=both timeStyle=full
timeZone=America/New_York/
/af:outputText
where demoInput.date returns the current date, e.g. June 17 09, 1:00 PM
2. Run the jsp. For June 17 09 the timezone is actually EDT (GMT - 4).
Instead it displays as EST
6/17/2009 1:00:00 PM GMT-05:00
If using the JSF standard DateTimeConverter, the output is:
Jun 17, 2009 1:00:00 PM EDT
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1512) ConvertDateTime uses static GMT+x string for timezone display, doesn't update for daylight savings
[
https://issues.apache.org/jira/browse/TRINIDAD-1512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12733903#action_12733903
]
Yee-Wah Lee commented on TRINIDAD-1512:
---
Although this used to work in JDK 1.5, I'm not convinced this is a JDK issue.
Since we are creating a custom timezone in getFormattingTimeZone(), and the JDK
documentation states: No daylight saving time transition schedule can be
specified with a custom time zone ID.
http://java.sun.com/javase/6/docs/api/java/util/TimeZone.html#setID%28java.lang.String
We used to clone the TimeZone so it would have the DST transition rules, and
the JDK 6 code now enforces that those rules aren't even looked at when
creating the timezone's display name.
Instead of using the DST transition rules, the DateTimeConverter can get the
formattingTimeZone() with the value to be formatted included, so it instead
does:
StringBuilder zoneId = new StringBuilder(9);
int offset = zone.getOffset((Date) value);
ConvertDateTime uses static GMT+x string for timezone display, doesn't update
for daylight savings
--
Key: TRINIDAD-1512
URL: https://issues.apache.org/jira/browse/TRINIDAD-1512
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Affects Versions: 1.2.11-core
Reporter: Yee-Wah Lee
Priority: Minor
1. Create a jsp that uses tr:convertDateTime to display timezone, e.g.
af:outputText value=#{demoInput.date}
af:convertDateTime type=both timeStyle=full
timeZone=America/New_York/
/af:outputText
where demoInput.date returns the current date, e.g. June 17 09, 1:00 PM
2. Run the jsp. For June 17 09 the timezone is actually EDT (GMT - 4).
Instead it displays as EST
6/17/2009 1:00:00 PM GMT-05:00
If using the JSF standard DateTimeConverter, the output is:
Jun 17, 2009 1:00:00 PM EDT
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1512) ConvertDateTime uses static GMT+x string for timezone display, doesn't update for daylight savings
[
https://issues.apache.org/jira/browse/TRINIDAD-1512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12729445#action_12729445
]
Yee-Wah Lee commented on TRINIDAD-1512:
---
Problem seen starting from JDK 1.6.0, not in any of the 1.5 (I tested up to
1.5.0_18).
ConvertDateTime uses static GMT+x string for timezone display, doesn't update
for daylight savings
--
Key: TRINIDAD-1512
URL: https://issues.apache.org/jira/browse/TRINIDAD-1512
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Affects Versions: 1.2.11-core
Reporter: Yee-Wah Lee
Priority: Minor
1. Create a jsp that uses tr:convertDateTime to display timezone, e.g.
af:outputText value=#{demoInput.date}
af:convertDateTime type=both timeStyle=full
timeZone=America/New_York/
/af:outputText
where demoInput.date returns the current date, e.g. June 17 09, 1:00 PM
2. Run the jsp. For June 17 09 the timezone is actually EDT (GMT - 4).
Instead it displays as EST
6/17/2009 1:00:00 PM GMT-05:00
If using the JSF standard DateTimeConverter, the output is:
Jun 17, 2009 1:00:00 PM EDT
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1521) Grammatical error in Date time converter format message
[ https://issues.apache.org/jira/browse/TRINIDAD-1521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12725711#action_12725711 ] Yee-Wah Lee commented on TRINIDAD-1521: --- File: trinidad-api\src\main\xrts\org\apache\myfaces\trinidad\resource\MessageBundle.xrts Key: org.apache.myfaces.trinidad.convert.DateTimeConverter.CONVERT_BOTH Message: The date and time is in not the correct format. Grammatical error in Date time converter format message --- Key: TRINIDAD-1521 URL: https://issues.apache.org/jira/browse/TRINIDAD-1521 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 1.2.11-core Reporter: Yee-Wah Lee Priority: Trivial There is a minor issue in the ADF Faces localization text for the date time converter. If you enter an invalid date format, the error that appears states that The date and time is in not the correct format. The word in and not appear to be transposed, such that the error message SHOULD say something more like The date and time is not in the correct format. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1521) Grammatical error in Date time converter format message
Grammatical error in Date time converter format message --- Key: TRINIDAD-1521 URL: https://issues.apache.org/jira/browse/TRINIDAD-1521 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 1.2.11-core Reporter: Yee-Wah Lee Priority: Trivial There is a minor issue in the ADF Faces localization text for the date time converter. If you enter an invalid date format, the error that appears states that The date and time is in not the correct format. The word in and not appear to be transposed, such that the error message SHOULD say something more like The date and time is not in the correct format. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1512) ConvertDateTime uses static GMT+x string for timezone display, doesn't update for daylight savings
ConvertDateTime uses static GMT+x string for timezone display, doesn't update
for daylight savings
--
Key: TRINIDAD-1512
URL: https://issues.apache.org/jira/browse/TRINIDAD-1512
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Affects Versions: 1.2.11-core
Reporter: Yee-Wah Lee
Priority: Minor
1. Create a jsp that uses tr:convertDateTime to display timezone, e.g.
af:outputText value=#{demoInput.date}
af:convertDateTime type=both timeStyle=full
timeZone=America/New_York/
/af:outputText
where demoInput.date returns the current date, e.g. June 17 09, 1:00 PM
2. Run the jsp. For June 17 09 the timezone is actually EDT (GMT - 4). Instead
it displays as EST
6/17/2009 1:00:00 PM GMT-05:00
If using the JSF standard DateTimeConverter, the output is:
Jun 17, 2009 1:00:00 PM EDT
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1512) ConvertDateTime uses static GMT+x string for timezone display, doesn't update for daylight savings
[
https://issues.apache.org/jira/browse/TRINIDAD-1512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12720772#action_12720772
]
Yee-Wah Lee commented on TRINIDAD-1512:
---
This is related to the code in
trinidadinternal.convert.DateTimeConverter#getFormattingTimeZone(). In that
method, it copies the converter's timezone and gives the clone a custom ID:
// set the id as GMT Sign Hours : Minutes
StringBuilder zoneId = new StringBuilder(9);
int rawOffset = zone.getRawOffset();
..
int minutes = (rawOffset % _MILLIS_PER_HOUR) / _MILLIS_PER_MINUTE;
if (minutes 10)
{
zoneId.append('0');
}
zoneId.append(minutes);
zone.setID(zoneId.toString());
This sets the ID as GMT+rawOffset (raw offset is independent of dst) for the
timezone America/New_York, which is -5h.
Subsequently, when formatting the string, the underlying DateFormat calls
TimeZone.getDisplayName() which checks if a custom ID is specified and returns
that string.
String id = getID();
String[] names = getDisplayNames(id, locale);
if (names == null) {
if (id.startsWith(GMT)) {
char sign = id.charAt(3);
if (sign == '+' || sign == '-') {
return id;
}
}
ConvertDateTime uses static GMT+x string for timezone display, doesn't update
for daylight savings
--
Key: TRINIDAD-1512
URL: https://issues.apache.org/jira/browse/TRINIDAD-1512
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Affects Versions: 1.2.11-core
Reporter: Yee-Wah Lee
Priority: Minor
1. Create a jsp that uses tr:convertDateTime to display timezone, e.g.
af:outputText value=#{demoInput.date}
af:convertDateTime type=both timeStyle=full
timeZone=America/New_York/
/af:outputText
where demoInput.date returns the current date, e.g. June 17 09, 1:00 PM
2. Run the jsp. For June 17 09 the timezone is actually EDT (GMT - 4).
Instead it displays as EST
6/17/2009 1:00:00 PM GMT-05:00
If using the JSF standard DateTimeConverter, the output is:
Jun 17, 2009 1:00:00 PM EDT
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1512) ConvertDateTime uses static GMT+x string for timezone display, doesn't update for daylight savings
[
https://issues.apache.org/jira/browse/TRINIDAD-1512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12720783#action_12720783
]
Yee-Wah Lee commented on TRINIDAD-1512:
---
The zone.setID(..) code seems to be done because of performance reasons. If
the date time converter supported full strings in the timezone display, it
would have to send down the translations for the possible timezone names, e.g.
EDT, PST and Eastern Daylight Time, Pacific Standard Time.
Even if taking the commonly used timezones (300+ out of possible 500+), that
would add substantial size since the locale file data would serve all
converters on the page, and some could have timeStyle=full, some would have
timeStyle=long hence it would need to contain all formatting variants of the
timezone name.
ConvertDateTime uses static GMT+x string for timezone display, doesn't update
for daylight savings
--
Key: TRINIDAD-1512
URL: https://issues.apache.org/jira/browse/TRINIDAD-1512
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Affects Versions: 1.2.11-core
Reporter: Yee-Wah Lee
Priority: Minor
1. Create a jsp that uses tr:convertDateTime to display timezone, e.g.
af:outputText value=#{demoInput.date}
af:convertDateTime type=both timeStyle=full
timeZone=America/New_York/
/af:outputText
where demoInput.date returns the current date, e.g. June 17 09, 1:00 PM
2. Run the jsp. For June 17 09 the timezone is actually EDT (GMT - 4).
Instead it displays as EST
6/17/2009 1:00:00 PM GMT-05:00
If using the JSF standard DateTimeConverter, the output is:
Jun 17, 2009 1:00:00 PM EDT
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (TRINIDAD-1258) GenericEntry allows invalid locale parameter - XSS vulnerability in LocaleInfoScriptlet
[ https://issues.apache.org/jira/browse/TRINIDAD-1258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12689912#action_12689912 ] Yee-Wah Lee edited comment on TRINIDAD-1258 at 3/31/09 2:30 PM: Per Scott: Requests to the resource servlet should have access to a servlet request even in a portlet environment. When running JSF, you'll get the portlet request object, but you should always have a viewRoot. So as long as you check for the view root first, I think you'll be fine. GenericEntry allows invalid locale parameter - XSS vulnerability in LocaleInfoScriptlet --- Key: TRINIDAD-1258 URL: https://issues.apache.org/jira/browse/TRINIDAD-1258 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 1.2.9-core Reporter: Yee-Wah Lee Assignee: Matthias Weßendorf Priority: Critical Fix For: 1.0.11-core, 1.2.11-core Attachments: trin11_1258.diff, trin12_1258.diff, trin12_1258_add.diff 1. Run the inputDate demo http://www.irian.at/trinidad-demo/faces/components/inputDate.jspx 2. Open the inputDate popup and copy its URL using right click/Properties http://www.irian.at/trinidad-demo/faces/__ADFv__?_t=fred_red=cdvalue=122402520loc=enenc=utf-8 3. Modify the URL to replace the loc parameter value with scriptalert(document.cookie)/script http://www.irian.at/trinidad-demo/faces/__ADFv__?_t=fred_red=cdvalue=122402520loc=en%3Cscript%3Ealert%28document.cookie%29%3C/script%3Eenc=utf-8 4. Load the modified URL in the browser - an alert popup appears. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-1258) GenericEntry allows invalid locale parameter - XSS vulnerability in LocaleInfoScriptlet
[ https://issues.apache.org/jira/browse/TRINIDAD-1258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yee-Wah Lee updated TRINIDAD-1258: -- Status: Patch Available (was: Reopened) GenericEntry allows invalid locale parameter - XSS vulnerability in LocaleInfoScriptlet --- Key: TRINIDAD-1258 URL: https://issues.apache.org/jira/browse/TRINIDAD-1258 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 1.2.9-core Reporter: Yee-Wah Lee Assignee: Matthias Weßendorf Priority: Critical Fix For: 1.0.11-core, 1.2.11-core Attachments: trin11_1258.diff, trin12_1258.diff, trin12_1258_add.diff 1. Run the inputDate demo http://www.irian.at/trinidad-demo/faces/components/inputDate.jspx 2. Open the inputDate popup and copy its URL using right click/Properties http://www.irian.at/trinidad-demo/faces/__ADFv__?_t=fred_red=cdvalue=122402520loc=enenc=utf-8 3. Modify the URL to replace the loc parameter value with scriptalert(document.cookie)/script http://www.irian.at/trinidad-demo/faces/__ADFv__?_t=fred_red=cdvalue=122402520loc=en%3Cscript%3Ealert%28document.cookie%29%3C/script%3Eenc=utf-8 4. Load the modified URL in the browser - an alert popup appears. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1419) Trinidad chooseDate golden files break with daylight savings
Trinidad chooseDate golden files break with daylight savings
Key: TRINIDAD-1419
URL: https://issues.apache.org/jira/browse/TRINIDAD-1419
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Reporter: Yee-Wah Lee
This is a result of Trinidad-1349. The server and client both use the current
date (System.currentTimeMillis) to determine the timezone offset, called
baseTZOffset. If the date being rendered has a different timezone offset
(called currTZOffset), it will append the timezone offset of the server in that
particular date-link. The client uses currTZOffset to calculate how many hours
to adjust the selected date-time by.
The code solves the problem mentioned in the original bug, but it also causes
problems for the chooseDate golden files. The baseTZOffset shifts depending on
the current daylight settings, hence the link being generated will reflect that
difference.
For example, suppose chooseDate test uses current date as July 27 2005, and
timezone in trinidad-config is set to Pacific Standard Time. In PST, the
timezone offset is -8h (-480) . In PDT, the timezone offset is -7h (-420),
which is also the timezone offset of July 27 2005.
chooseDate golden file in PST
a onclick=return _calsd('dateid',112244760, -420)
because baseTZOffset = -480, currTZOffset = -420. The client needs to use -420
when calculating the timezone difference on that day.
chooseDate golden file in PDT:
a onclick=return _calsd('dateid',112244760)
because baseTZoffset = currTZOffset = -420. The client can directly use
baseTZoffset.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1414) Implement support for specifying ListString attribute type as String
Implement support for specifying ListString attribute type as String -- Key: TRINIDAD-1414 URL: https://issues.apache.org/jira/browse/TRINIDAD-1414 Project: MyFaces Trinidad Issue Type: Improvement Components: Plugins Reporter: Yee-Wah Lee Priority: Minor Today, attributes of type String[], e.g. partialTriggers, can be specified with a String. Trinidad provides convenience methods in UIXComponentTag.java#setStringArrayProperty() to allow the conversion of String-SetString. Propose adding similar convenience methods for types ListString and SetString as well. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1374) NumberConverter with type='number' and pattern set gives malformed error
NumberConverter with type='number' and pattern set gives malformed error
Key: TRINIDAD-1374
URL: https://issues.apache.org/jira/browse/TRINIDAD-1374
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Reporter: Yee-Wah Lee
Priority: Minor
1. Add an inputText with child numberConverter that has type='number' and a
pattern set.
e.g.
tr:inputText value=99.99 label=number converter1
f:facet name=help
tr:outputText value=type='number' integerOnly='true' - This
will result in fraction part to be omitted/
/f:facet
f:convertNumber type=number pattern=0.0/
/tr:inputText
2. Run the jspx and type in malformed input.
3. submit the page, the error message for the component is:
The format of the number must match this pattern: {2}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1374) NumberConverter with type='number' and pattern set gives malformed error
[
https://issues.apache.org/jira/browse/TRINIDAD-1374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12666324#action_12666324
]
Yee-Wah Lee commented on TRINIDAD-1374:
---
trinidad-api\src\main\java\org\apache\myfaces\trinidad\convert\NumberConverter.java
getAsObject() does:
if(currency.equals(type))
{
params = new Object[] {label, getPattern(),
fmt.format(_EXAMPLE_CURRENCY)};
}
else if(percent.equals(type))
{
params = new Object[] {label, getPattern(),
fmt.format(_EXAMPLE_PERCENT)};
}
else
{
params = new Object[] {label, getPattern()};
}
Then getConvertMessage() does:
if (_PATTERN_TYPE == type)
{
convMsgDet = _getRawConvertPatternMessageDetail();
msgId = CONVERT_PATTERN_MESSAGE_ID;
}
else if(_NUMBER_TYPE == type)
{
convMsgDet = _getRawConvertNumberMessageDetail();
msgId = CONVERT_NUMBER_MESSAGE_ID;
}
else if(_CURRENCY_TYPE == type)
{
convMsgDet = _getRawConvertCurrencyMessageDetail();
msgId = CONVERT_CURRENCY_MESSAGE_ID;
}
else if(_PERCENT_TYPE == type)
{
convMsgDet = _getRawConvertPercentMessageDetail();
msgId = CONVERT_PERCENT_MESSAGE_ID;
}
where CONVERT_PATTERN_MESSAGE_ID is given by:
{org.apache.myfaces.trinidad.convert.NumberConverter.CONVERT_PATTERN_detail,
The format of the number must match this pattern: {2}}
The problem is that {2} should be {1}, since in the constructed param array
params = new Object[] {label, getPattern()};
the pattern is at index 1.
Furthermore, getAsObject() should check for _PATTERN_TYPE first.
NumberConverter with type='number' and pattern set gives malformed error
Key: TRINIDAD-1374
URL: https://issues.apache.org/jira/browse/TRINIDAD-1374
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Reporter: Yee-Wah Lee
Priority: Minor
1. Add an inputText with child numberConverter that has type='number' and a
pattern set.
e.g.
tr:inputText value=99.99 label=number converter1
f:facet name=help
tr:outputText value=type='number' integerOnly='true' -
This will result in fraction part to be omitted/
/f:facet
f:convertNumber type=number pattern=0.0/
/tr:inputText
2. Run the jspx and type in malformed input.
3. submit the page, the error message for the component is:
The format of the number must match this pattern: {2}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1367) Date picker does not handle daylight savings transition hour well
Date picker does not handle daylight savings transition hour well - Key: TRINIDAD-1367 URL: https://issues.apache.org/jira/browse/TRINIDAD-1367 Project: MyFaces Trinidad Issue Type: Bug Components: Components Reporter: Yee-Wah Lee Priority: Minor 1. Run the client converter demo at $trinidad-demo-context-root/faces/convertValidate/clientConvert.jspx 2. Look for the example with label date converter and a validator that sets a maximum date of tonight 3. Modify the input to an hour during the daylight savings transition. For example, in the US clocks were set forward during 9 Mar 2008 2-2:59am, so enter 3/9/2008 2:30 AM 4. If client validationis enabled, the client converter silently converts it to 1:30am (when it should be set forward). If client validation is disabled, pressing Submit will return an misleading error message Enter a date and time in the same format as this example: 11/29/1998 3:45 PM. The date itself is well-formed , so the message is misleading. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1349) InputDate: wrong date-time selected when browser in summer time and server in winter time
[ https://issues.apache.org/jira/browse/TRINIDAD-1349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12663802#action_12663802 ] Yee-Wah Lee commented on TRINIDAD-1349: --- Martin, thanks for the patch. I think your fix will work for the case where the client is moving between summer/winter time. However, there should still be a problem where the server moves between summer/winter time and the picked dates on the client use the wrong timezone offset. I will be looking at that issue. InputDate: wrong date-time selected when browser in summer time and server in winter time - Key: TRINIDAD-1349 URL: https://issues.apache.org/jira/browse/TRINIDAD-1349 Project: MyFaces Trinidad Issue Type: Bug Components: Components Reporter: Yee-Wah Lee Priority: Minor Attachments: TRINIDAD-1349.patch 1. Create an inputDate with convertDateTime with type=both so date and time show up. You can also go to the demo (look for A inputDate with a converter attached from fr_BE locale (has 1-digit display for hours). 2. Run the server in Pacific Time, current date 11 Nov 2008. 3. Open a browser on another machine with timezone Western Australia, current time 11 Nov 2008. 4. Open the date picker, and pick a date in summer, e.g. 15 Mar 2008 The resulting date shows a different day and/or a different time offset. On the demo, I pick 15 Mar and see: dimanche 16 mars 2008 5:44 Previously the value was mardi 16 décembre 2008 21:45, so it should have retained the hours/mins from the previous value (21:45) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1349) InputDate: wrong date-time selected when browser in summer time and server in winter time
InputDate: wrong date-time selected when browser in summer time and server in winter time - Key: TRINIDAD-1349 URL: https://issues.apache.org/jira/browse/TRINIDAD-1349 Project: MyFaces Trinidad Issue Type: Bug Components: Components Reporter: Yee-Wah Lee Priority: Minor 1. Create an inputDate with convertDateTime with type=both so date and time show up. You can also go to the demo (look for A inputDate with a converter attached from fr_BE locale (has 1-digit display for hours). 2. Run the server in Pacific Time, current date 11 Nov 2008. 3. Open a browser on another machine with timezone Western Australia, current time 11 Nov 2008. 4. Open the date picker, and pick a date in summer, e.g. 15 Mar 2008 The resulting date shows a different day and/or a different time offset. On the demo, I pick 15 Mar and see: dimanche 16 mars 2008 5:44 Previously the value was mardi 16 décembre 2008 21:45, so it should have retained the hours/mins from the previous value (21:45) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1258) GenericEntry allows invalid locale parameter - XSS vulnerability in LocaleInfoScriptlet
[ https://issues.apache.org/jira/browse/TRINIDAD-1258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12646767#action_12646767 ] Yee-Wah Lee commented on TRINIDAD-1258: --- Uploading patch for 1.1 and 1.2 trunks that: - Verifies that the language and country arguments used in creating a Locale object (constructor takes language, country, variant) are valid per Javadoc standards before creating it. For variant, it is vendor-specific, it just checks for slashes and rejects them due to XSS. - logs warning if any of the arguments fail to pass, and uses default or empty - Fixes NamedLocaleInfoScriptlet to work with the change. In the original TRINIDAD-797 fix, it would add the argument in getLibraryURL but with the fix added by TRINIDAD-879, there were two '?' delimiters in the request. The skipTranslations argument was mangled with the locale argument so the code to retrieve the Locale would fail (since the language code was 2 characters) and the requested locale was not loaded. The fix is to override addExtraParams() and add the additional parameter correctly. GenericEntry allows invalid locale parameter - XSS vulnerability in LocaleInfoScriptlet --- Key: TRINIDAD-1258 URL: https://issues.apache.org/jira/browse/TRINIDAD-1258 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 1.2.9-core Reporter: Yee-Wah Lee Assignee: Matthias Weßendorf Priority: Critical Attachments: trin11_1258.diff, trin12_1258.diff 1. Run the inputDate demo http://www.irian.at/trinidad-demo/faces/components/inputDate.jspx 2. Open the inputDate popup and copy its URL using right click/Properties http://www.irian.at/trinidad-demo/faces/__ADFv__?_t=fred_red=cdvalue=122402520loc=enenc=utf-8 3. Modify the URL to replace the loc parameter value with scriptalert(document.cookie)/script http://www.irian.at/trinidad-demo/faces/__ADFv__?_t=fred_red=cdvalue=122402520loc=en%3Cscript%3Ealert%28document.cookie%29%3C/script%3Eenc=utf-8 4. Load the modified URL in the browser - an alert popup appears. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-797) Date-picker does not use the converter's locale attribute if it differs from page locale
[
https://issues.apache.org/jira/browse/TRINIDAD-797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12646771#action_12646771
]
Yee-Wah Lee commented on TRINIDAD-797:
--
Please see TRINIDAD-1258 for an amendment to this fix (in how the locale
parameter is added)
Date-picker does not use the converter's locale attribute if it differs from
page locale
Key: TRINIDAD-797
URL: https://issues.apache.org/jira/browse/TRINIDAD-797
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Reporter: Yee-Wah Lee
Priority: Minor
Fix For: 1.0.5-core
Attachments: trin11_797_deferredRenderers.patch,
trin12_797_deferredRenderers.patch, Trinidad11_797.patch
1. Suppose the page locale is en_us. Add an inputDate to the jspx with a
converter of a different locale, e.g.
tr:inputDate id=mdf6 value=#{date.date4}
label=attached converter
tr:convertDateTime type=date dateStyle=full
locale=fr_FR/
/tr:inputDate
2. Run the page - the inputDate shows up with the text in french, as expected.
3. Open the picker, and pick a different date.
4. When the picker closes, the inputDate has been updated with the Date in
English.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1258) GenericEntry allows invalid locale parameter - XSS vulnerability in LocaleInfoScriptlet
GenericEntry allows invalid locale parameter - XSS vulnerability in LocaleInfoScriptlet --- Key: TRINIDAD-1258 URL: https://issues.apache.org/jira/browse/TRINIDAD-1258 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 1.2.9-core Reporter: Yee-Wah Lee Priority: Minor 1. Run the inputDate demo http://www.irian.at/trinidad-demo/faces/components/inputDate.jspx 2. Open the inputDate popup and copy its URL using right click/Properties http://www.irian.at/trinidad-demo/faces/__ADFv__?_t=fred_red=cdvalue=122402520loc=enenc=utf-8 3. Modify the URL to replace the loc parameter value with scriptalert(document.cookie)/script http://www.irian.at/trinidad-demo/faces/__ADFv__?_t=fred_red=cdvalue=122402520loc=en%3Cscript%3Ealert%28document.cookie%29%3C/script%3Eenc=utf-8 4. Load the modified URL in the browser - an alert popup appears. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-1150) Problem upgrading to version 1.0.5 (or 2.0.8) of trinidad with customized renderkit
[ https://issues.apache.org/jira/browse/TRINIDAD-1150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yee-Wah Lee updated TRINIDAD-1150: -- Status: Patch Available (was: Open) Problem upgrading to version 1.0.5 (or 2.0.8) of trinidad with customized renderkit --- Key: TRINIDAD-1150 URL: https://issues.apache.org/jira/browse/TRINIDAD-1150 Project: MyFaces Trinidad Issue Type: Bug Components: Components Reporter: Yee-Wah Lee Attachments: trin11_797_deferredRenderers.patch, trin12_797_deferredRenderers.patch Sample error message when trying to upgrade from Trinidad 1.2.1 to 1.2.8, and when user has own renderkit. SEVERE: Exception sending context initialized event to listener instance of class com.sun.faces.config.ConfigureListener java.lang.ExceptionInInitializerError at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.jsLibs.Scriptlet.registerSelfWithKey(Scriptlet.java:163) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.jsLibs.Scriptlet.registerSelf(Scriptlet.java:92) ... Caused by: java.lang.NullPointerException at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.jsLibs.LocaleInfoScriptlet.getSupportedLocaleVariant(LocaleInfoScriptlet.java:168) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.jsLibs.NamedLocaleInfoScriptlet.init(NamedLocaleInfoScriptlet.java:62) ... This was caused by the patch for Trinidad-797 which assumed delay loading of renders, which the core trinidad renderkit implemented. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1150) Problem upgrading to version 1.0.5 (or 2.0.8) of trinidad with customized renderkit
Problem upgrading to version 1.0.5 (or 2.0.8) of trinidad with customized renderkit --- Key: TRINIDAD-1150 URL: https://issues.apache.org/jira/browse/TRINIDAD-1150 Project: MyFaces Trinidad Issue Type: Bug Components: Components Reporter: Yee-Wah Lee Attachments: trin11_797_deferredRenderers.patch, trin12_797_deferredRenderers.patch Sample error message when trying to upgrade from Trinidad 1.2.1 to 1.2.8, and when user has own renderkit. SEVERE: Exception sending context initialized event to listener instance of class com.sun.faces.config.ConfigureListener java.lang.ExceptionInInitializerError at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.jsLibs.Scriptlet.registerSelfWithKey(Scriptlet.java:163) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.jsLibs.Scriptlet.registerSelf(Scriptlet.java:92) ... Caused by: java.lang.NullPointerException at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.jsLibs.LocaleInfoScriptlet.getSupportedLocaleVariant(LocaleInfoScriptlet.java:168) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.jsLibs.NamedLocaleInfoScriptlet.init(NamedLocaleInfoScriptlet.java:62) ... This was caused by the patch for Trinidad-797 which assumed delay loading of renders, which the core trinidad renderkit implemented. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-1150) Problem upgrading to version 1.0.5 (or 2.0.8) of trinidad with customized renderkit
[ https://issues.apache.org/jira/browse/TRINIDAD-1150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yee-Wah Lee updated TRINIDAD-1150: -- Status: Open (was: Patch Available) Problem upgrading to version 1.0.5 (or 2.0.8) of trinidad with customized renderkit --- Key: TRINIDAD-1150 URL: https://issues.apache.org/jira/browse/TRINIDAD-1150 Project: MyFaces Trinidad Issue Type: Bug Components: Components Reporter: Yee-Wah Lee Attachments: trin11_797_deferredRenderers.patch, trin12_797_deferredRenderers.patch Sample error message when trying to upgrade from Trinidad 1.2.1 to 1.2.8, and when user has own renderkit. SEVERE: Exception sending context initialized event to listener instance of class com.sun.faces.config.ConfigureListener java.lang.ExceptionInInitializerError at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.jsLibs.Scriptlet.registerSelfWithKey(Scriptlet.java:163) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.jsLibs.Scriptlet.registerSelf(Scriptlet.java:92) ... Caused by: java.lang.NullPointerException at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.jsLibs.LocaleInfoScriptlet.getSupportedLocaleVariant(LocaleInfoScriptlet.java:168) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.jsLibs.NamedLocaleInfoScriptlet.init(NamedLocaleInfoScriptlet.java:62) ... This was caused by the patch for Trinidad-797 which assumed delay loading of renders, which the core trinidad renderkit implemented. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1061) Regression: CommandButton blocking on PPR doesn't work on IE
Regression: CommandButton blocking on PPR doesn't work on IE
Key: TRINIDAD-1061
URL: https://issues.apache.org/jira/browse/TRINIDAD-1061
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Environment: IE browser
Reporter: Yee-Wah Lee
Priority: Minor
This is a regression from TRINIDAD-952.
1. Create a command button that calls a server side method and which has the
blocking attribute set to true.
2. Run the debugger, and put a breakpoint in the server method.
3. Press the command button once - debugger stops at the server method. Press
the button again.
4. Let the debugger continue, and note that it stops again at the method - the
second click was not blocked.
af:commandButton text=Search blocking=true action=#{date.doSearch}
partialSubmit=true/\
public String doSearch ()
{
System.out.println(searchAction method invoked);
return ;
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1036) Client Color Converter's getFormatHint() returns empty string for the hints.
[
https://issues.apache.org/jira/browse/TRINIDAD-1036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12585801#action_12585801
]
Yee-Wah Lee commented on TRINIDAD-1036:
---
Attachment works for both trunk and jsf 1.2.6 branch.
Client Color Converter's getFormatHint() returns empty string for the hints.
-
Key: TRINIDAD-1036
URL: https://issues.apache.org/jira/browse/TRINIDAD-1036
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Reporter: Yee-Wah Lee
Priority: Minor
Attachments: trin11_1036.diff
1. Sample code to create a button which, when clicked, gets the format hint
for a color field and displays it in an output text.
f:verbatim
script language=javascript
function getHint ()
{
var colorField = document.getElementById (sic1);
var format = _getColorFieldFormat (colorField);
var colorHint = document.getElementById (help_sic1);
colorHint.textContent = format.getFormatHint ();
}
/script
/f:verbatim
tr:inputColor id=sic1 chooseId=cp1
label=Enter or select color from palette below
f:facet name=help
tr:outputText id=help_sic1 value=Format hint goes here if
button is clicked/
/f:facet
/tr:inputColor
tr:commandButton onclick=getHint(this); return false;
text=Click for color hint/
2. Run the page and click the button - the output text is updated with the
string Example Format: . It should instead reflect the patterns for the
inputColor which are defaulted in the example above, i.e. Example Format:
RRGGBB, #RRGGBB, r,g,b
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1036) Client Color Converter's getFormatHint() returns empty string for the hints.
Client Color Converter's getFormatHint() returns empty string for the hints.
-
Key: TRINIDAD-1036
URL: https://issues.apache.org/jira/browse/TRINIDAD-1036
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Reporter: Yee-Wah Lee
Priority: Minor
1. Sample code to create a button which, when clicked, gets the format hint for
a color field and displays it in an output text.
f:verbatim
script language=javascript
function getHint ()
{
var colorField = document.getElementById (sic1);
var format = _getColorFieldFormat (colorField);
var colorHint = document.getElementById (help_sic1);
colorHint.textContent = format.getFormatHint ();
}
/script
/f:verbatim
tr:inputColor id=sic1 chooseId=cp1
label=Enter or select color from palette below
f:facet name=help
tr:outputText id=help_sic1 value=Format hint goes here if
button is clicked/
/f:facet
/tr:inputColor
tr:commandButton onclick=getHint(this); return false; text=Click
for color hint/
2. Run the page and click the button - the output text is updated with the
string Example Format: . It should instead reflect the patterns for the
inputColor which are defaulted in the example above, i.e. Example Format:
RRGGBB, #RRGGBB, r,g,b
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1036) Client Color Converter's getFormatHint() returns empty string for the hints.
[
https://issues.apache.org/jira/browse/TRINIDAD-1036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12584295#action_12584295
]
Yee-Wah Lee commented on TRINIDAD-1036:
---
I think this used to be work before the changes in TRINIDAD-829 and
TRINIDAD-873.
Between these two changes, the method TrFastMessageFormatUtils.format() now
works with strings whereas the color converter uses an Array of strings , e.g.
[RRGGBB, #RRGGBB, r,g,b].
Client Color Converter's getFormatHint() returns empty string for the hints.
-
Key: TRINIDAD-1036
URL: https://issues.apache.org/jira/browse/TRINIDAD-1036
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Reporter: Yee-Wah Lee
Priority: Minor
1. Sample code to create a button which, when clicked, gets the format hint
for a color field and displays it in an output text.
f:verbatim
script language=javascript
function getHint ()
{
var colorField = document.getElementById (sic1);
var format = _getColorFieldFormat (colorField);
var colorHint = document.getElementById (help_sic1);
colorHint.textContent = format.getFormatHint ();
}
/script
/f:verbatim
tr:inputColor id=sic1 chooseId=cp1
label=Enter or select color from palette below
f:facet name=help
tr:outputText id=help_sic1 value=Format hint goes here if
button is clicked/
/f:facet
/tr:inputColor
tr:commandButton onclick=getHint(this); return false;
text=Click for color hint/
2. Run the page and click the button - the output text is updated with the
string Example Format: . It should instead reflect the patterns for the
inputColor which are defaulted in the example above, i.e. Example Format:
RRGGBB, #RRGGBB, r,g,b
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1020) Incomplete fix for TRINIDAD-61 (tr:validateDateTimeRange validation fails on last day of valid range)
Incomplete fix for TRINIDAD-61 (tr:validateDateTimeRange validation fails on last day of valid range) - Key: TRINIDAD-1020 URL: https://issues.apache.org/jira/browse/TRINIDAD-1020 Project: MyFaces Trinidad Issue Type: Bug Components: Components Reporter: Yee-Wah Lee Priority: Minor Attachments: trin11_61_add_2.diff 1. Run the application in a different timezone than the server by setting time-zone parameter in trinidad-config.xml. Use a timezone is 'ahead' of the user's, e.g. if user is in PST (GMT-8), use Europe/Stockholm (which is GMT+1) 2. Run the demo page clientConvert.jspx and enter '12-31-2007' for the date which is restricted to be within 2007. 3. Fill in the other fields and submit the page - the client validator does not give an error, but the server validator does. The reasons are given in the latest comments on TRINIDAD-61. Since that issue was closed, I'm filing a new one here for tracking. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-965) cursor does not appear to go anywhere after PPR if next tabbed component was updated
[
https://issues.apache.org/jira/browse/TRINIDAD-965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12580948#action_12580948
]
Yee-Wah Lee commented on TRINIDAD-965:
--
I backed ou TRINIDAD-952 locally, and find that the problem still occurs for
FF.
cursor does not appear to go anywhere after PPR if next tabbed component was
updated
Key: TRINIDAD-965
URL: https://issues.apache.org/jira/browse/TRINIDAD-965
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Affects Versions: 1.0.6-core
Environment: IE 7/Firefox 2
Reporter: Paul Mander
Priority: Minor
Test case based on TRINIDAD-952
tr:inputText label=Label 1
id=inputText1
binding=#{tabfails.inputText1}
autoSubmit=true
valueChangeListener=#{tabfails.doSomething1}/
tr:inputText label=Label 2
id=inputText2
binding=#{tabfails.inputText2}
partialTriggers=inputText1 /
tr:inputText label=Label 3
id=inputText3
binding=#{tabfails.inputText3}
partialTriggers=inputText1/
public void doSomething1(ValueChangeEvent valueChangeEvent) {
String value1 = inputText1.getValue() == null ? null :
inputText1.getValue().toString();
String value2 = inputText2.getValue() == null ? null :
inputText2.getValue().toString();
inputText2.setSubmittedValue(null);
inputText2.setValue(value1 + value2);
}
Enter anything in inputtext1 and tab. InputText2 is updated but no component
appears to have focus.
Note that in 1.0.6, different behaviour was seen between IE and Firefox. IE
would maintain focus back on tabbed from input. Since TRINIDAD-952 both
browsers behave the same.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
