[jira] [Updated] (TRINIDAD-2511) rounding mode is not honoured on the client while using number converter
[ https://issues.apache.org/jira/browse/TRINIDAD-2511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ashwin Prabhu updated TRINIDAD-2511: Status: Patch Available (was: Open) > rounding mode is not honoured on the client while using number converter > > > Key: TRINIDAD-2511 > URL: https://issues.apache.org/jira/browse/TRINIDAD-2511 > Project: MyFaces Trinidad > Issue Type: Bug > Components: Components >Affects Versions: 2.1.0-core >Reporter: Ashwin Prabhu > Original Estimate: 24h > Remaining Estimate: 24h > > When rounding mode is specified on af:convertNumber, decimal truncation > affected by min/max fraction digits should be governed by the rounding mode > specified. > Currently client side number converter (TrNumberConverter) performs decimal > truncation when maxFractionDigits is specified without considering the > rounding mode chosen. This leads to data inconsistencies when > af:convertNumber is attached to input components. > For ex: > > > > the above converts 5.551 to 5.55, wheras the correct rounding should have > been 5.56, since the rounding mode is UP. > However, since he server side converter correctly implements rounding, the > issue does not arise when the converter is attached to output components. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TRINIDAD-2511) rounding mode is not honoured on the client while using number converter
Ashwin Prabhu created TRINIDAD-2511: --- Summary: rounding mode is not honoured on the client while using number converter Key: TRINIDAD-2511 URL: https://issues.apache.org/jira/browse/TRINIDAD-2511 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.1.0-core Reporter: Ashwin Prabhu When rounding mode is specified on af:convertNumber, decimal truncation affected by min/max fraction digits should be governed by the rounding mode specified. Currently client side number converter (TrNumberConverter) performs decimal truncation when maxFractionDigits is specified without considering the rounding mode chosen. This leads to data inconsistencies when af:convertNumber is attached to input components. For ex: the above converts 5.551 to 5.55, wheras the correct rounding should have been 5.56, since the rounding mode is UP. Since he server side converter correctly implements rounding, the issue does not arise when the converter is attached to output components. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TRINIDAD-2506) Ensure all the Trinidad Validators are compliant with version 2 of JSF specification
[ https://issues.apache.org/jira/browse/TRINIDAD-2506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ashwin Prabhu updated TRINIDAD-2506: Status: Patch Available (was: Open) > Ensure all the Trinidad Validators are compliant with version 2 of JSF > specification > > > Key: TRINIDAD-2506 > URL: https://issues.apache.org/jira/browse/TRINIDAD-2506 > Project: MyFaces Trinidad > Issue Type: Bug > Components: Components >Affects Versions: 2.1.0-core >Reporter: Ashwin Prabhu > Original Estimate: 24h > Remaining Estimate: 24h > > As per the JSF 2 spec, validators would be invoked on empty/null value > submissions. This differs from the 1.2 behavior, where validators were > invoked only on non-null or non-empty fields. > Validators that are the part of Trinidad distribution, like: RegExpValidator, > LengthValidator are not JSF ver. 2.0 compliant and hence choke on null/empty > values. These need to be corrected. > The new spec has the following to say about the validation behavior going > ahead: > "For a validator to be fully compliant with Version 2 and later of the > specification, it must not fail validation on null or empty values unless it > is specifically intended to address null or empty values. An application-wide > is provided to allow validators designed for JSF 1.2 to work > with JSF 2 and later. The javax.faces.VALIDATE_EMPTY_FIELDS > must be set to false to enable this backwards compatibility behavior." > More info here: > http://docs.oracle.com/javaee/7/api/javax/faces/validator/Validator.html#validate(javax.faces.context.FacesContext, > javax.faces.component.UIComponent, java.lang.Object) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (TRINIDAD-2506) Ensure all the Trinidad Validators are compliant with version 2 of JSF specification
Ashwin Prabhu created TRINIDAD-2506: --- Summary: Ensure all the Trinidad Validators are compliant with version 2 of JSF specification Key: TRINIDAD-2506 URL: https://issues.apache.org/jira/browse/TRINIDAD-2506 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.1.0-core Reporter: Ashwin Prabhu As per the JSF 2 spec, validators should be invoked on empty/null value submissions. This differs from the 1.2 behavior, where validators were invoked only on non-null or non-empty fields. Validators that are the part of Trinidad distribution, like: RegExpValidator, LengthValidator are not ver 2.0 compilant and hence choke on null/empty values. These need to be corrected. The new spec has the following to say about the validation behavior going ahead: "For a validator to be fully compliant with Version 2 and later of the specification, it must not fail validation on null or empty values unless it is specifically intended to address null or empty values. An application-wide is provided to allow validators designed for JSF 1.2 to work with JSF 2 and later. The javax.faces.VALIDATE_EMPTY_FIELDS must be set to false to enable this backwards compatibility behavior." More info here: http://docs.oracle.com/javaee/7/api/javax/faces/validator/Validator.html#validate(javax.faces.context.FacesContext, javax.faces.component.UIComponent, java.lang.Object) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TRINIDAD-2496) Support custom negative prefix and suffix on af:convertNumber
[ https://issues.apache.org/jira/browse/TRINIDAD-2496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ashwin Prabhu updated TRINIDAD-2496: Status: Patch Available (was: Open) > Support custom negative prefix and suffix on af:convertNumber > - > > Key: TRINIDAD-2496 > URL: https://issues.apache.org/jira/browse/TRINIDAD-2496 > Project: MyFaces Trinidad > Issue Type: Improvement > Components: Components >Reporter: Ashwin Prabhu > Original Estimate: 168h > Remaining Estimate: 168h > > This is an enhancement request of af:convertNumber (converter class is > NumberConverter) to support additional conversion function for negative > numbers. > It is expected to enhance af:convertNumber (converter class is > NumberConverter) to support the following: > 1. new attribute of negativePrefix and negativeSuffix > 2. parsing/formatting support in both client and server side using negative > prefix/suffix > -- > Problem description: > Financial applications sometimes require that negative numbers be displayed > within () instead of the usual -ve prefix. Ex: -1234 as (1234). > Currently Trinidad based applications can achieve this by specifying a > pattern on the number converter, like for example "#;(#)". This works, but > the caveat is that patterns are not processed by the client converter. So > essentially to parse and format numbers, the application must wait until the > input is eventually submitted to the server or perform a auto-submit to > expedite the validation. Performing auto-submit to validate the input for > converter pattern compliance is noticeably slow and wastes a server round > trip. So the request is to enhance the client converter to parse/format > numbers with suffix/prefix on the client and this should work for all types: > number, percent, currency(already works). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (TRINIDAD-2496) Support custom negative prefix and suffix on af:convertNumber
Ashwin Prabhu created TRINIDAD-2496: --- Summary: Support custom negative prefix and suffix on af:convertNumber Key: TRINIDAD-2496 URL: https://issues.apache.org/jira/browse/TRINIDAD-2496 Project: MyFaces Trinidad Issue Type: Improvement Components: Components Reporter: Ashwin Prabhu This is an enhancement request of af:convertNumber (converter class is NumberConverter) to support additional conversion function for negative numbers. It is expected to enhance af:convertNumber (converter class is NumberConverter) to support the following: 1. new attribute of negativePrefix and negativeSuffix 2. parsing/formatting support in both client and server side using negative prefix/suffix -- Problem description: Financial applications sometimes require that negative numbers be displayed within () instead of the usual -ve prefix. Ex: -1234 as (1234). Currently Trinidad based applications can achieve this by specifying a pattern on the number converter, like for example "#;(#)". This works, but the caveat is that patterns are not processed by the client converter. So essentially to parse and format numbers, the application must wait until the input is eventually submitted to the server or perform a auto-submit to expedite the validation. Performing auto-submit to validate the input for converter pattern compliance is noticeably slow and wastes a server round trip. So the request is to enhance the client converter to parse/format numbers with suffix/prefix on the client and this should work for all types: number, percent, currency(already works). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TRINIDAD-2495) af:convertnumber: currencysymbol and currencycode support is broken
[ https://issues.apache.org/jira/browse/TRINIDAD-2495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ashwin Prabhu updated TRINIDAD-2495: Status: Patch Available (was: Open) > af:convertnumber: currencysymbol and currencycode support is broken > --- > > Key: TRINIDAD-2495 > URL: https://issues.apache.org/jira/browse/TRINIDAD-2495 > Project: MyFaces Trinidad > Issue Type: Bug > Components: Components >Affects Versions: 2.1.0-core >Reporter: Ashwin Prabhu > Original Estimate: 24h > Remaining Estimate: 24h > > af:convertNumber's CurrencySymbol and currencyCode attributes on > af:convertNumber are no longer functioning as documented. Specifying any > value other than the locale default for the currencyCode/Symbol generates a > client side error. > For ex: > > > > The above will throw the following error on the client side: > Error: The currency format is incorrect. > Enter a currency in the same format as this example: $10,250.00 > Ditto for currencyCode. > Similar problems exist on the server side converter too. The DecimalFormatter > is not made aware of the custom currency and hence chokes on anything > non-standard for currency code/symbol. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (TRINIDAD-2495) af:convertnumber: currencysymbol and currencycode support is broken
Ashwin Prabhu created TRINIDAD-2495: --- Summary: af:convertnumber: currencysymbol and currencycode support is broken Key: TRINIDAD-2495 URL: https://issues.apache.org/jira/browse/TRINIDAD-2495 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.1.0-core Reporter: Ashwin Prabhu af:convertNumber's CurrencySymbol and currencyCode attributes on af:convertNumber are no longer functioning as documented. Specifying any value other than the locale default for the currencyCode/Symbol generates a client side error. For ex: The above will throw the following error on the client side: Error: The currency format is incorrect. Enter a currency in the same format as this example: $10,250.00 Ditto for currencyCode. Similar problems exist on the server side converter too. The DecimalFormatter is not made aware of the custom currency and hence chokes on anything non-standard for currency code/symbol. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TRINIDAD-2485) Some attribute behaviors in tr:validateDateRestriction donot match their documentation
[
https://issues.apache.org/jira/browse/TRINIDAD-2485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ashwin Prabhu updated TRINIDAD-2485:
Status: Patch Available (was: Open)
> Some attribute behaviors in tr:validateDateRestriction donot match their
> documentation
> --
>
> Key: TRINIDAD-2485
> URL: https://issues.apache.org/jira/browse/TRINIDAD-2485
> Project: MyFaces Trinidad
> Issue Type: Bug
> Components: Components
>Affects Versions: 2.1.0-core
>Reporter: Ashwin Prabhu
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> There are several issues in tr:validateDateRestriction. Here's a
> attribute-wise list of problems which need to be fixed:
> Attribute: invalidDays
> The start and end dates passed into the method getDateList of
> DateListProvider needs to be 24 hour wide. Currently the same date is passed
> for start and end range, defeating the purpose of haveing 2 parameters. The
> current arrangement works only if DateListProvider strictly goes by the date
> part and ignores the time component in the start and end range.
> The documentation of DateListProvider has this:
> rangeStart - The start of the range for which dates are being requested.
> rangeEnd - The end of the range for which dates are being requested.
> Although not literallly mentioned, the implicit messaging of the parmater
> description suggests the time part of the date range cannot be ignored.
> Attribute: messageDetailInvalidDaysOfWeek
> The documentation of message parameters states this:
> {0} the label that identifies the component
> {1} value entered by the user
> {2} the invalid weekday
> Currently the values passed as 3rd parameter ({2}) on the client contains a
> list of all the days of the week, but for the user selected week. This
> behavior is wrong as per the documentation. To see this behavior in acion
> please visit
> http://example.irian.at/trinidad-demo/faces/convertValidate/dateRestrictionValidate.jspx
> and select any monday in the 3rd input Date. You will see a error message
> "Enter a date that is on one of the following days: Tuesday, Wednesday,
> Thursday, Friday, Saturday, Sunday". Here both the message and the week-day
> parameters are worng. On the server however this is done as per the
> documentation, but the passed in weekday is not localized, but picked up from
> the internal _dayMap map containing the week days as "sun", "mon""sat" .
> To summarize,
> The client validator needs to pass in parameters as per the documentation.
> The server validator needs to localize the substituted week days.
> THe message bundle string is currently "Enter a date that falls on one of the
> following days: {0}" also needs to be changed to match the intention in the
> tag document.
> Attribute: messageDetailInvalidMonths
> The documentation of message parameters states this:
> {0} the label that identifies the component
> {1} value entered by the user
> {2} the invalid month
> Currently the values passed as 3rd parameter ({2}) on the client contains a
> list of all the months of the year, but for the user selected month. This
> behavior is wrong as per the documentation. To see this behavior in acion
> please visit
> http://example.irian.at/trinidad-demo/faces/convertValidate/dateRestrictionValidate.jspx
> and select any day in November in the 2rd input Date. You will see a error
> message "November/December dates are not allowed here!
> Enter a date in one of the following months: January, February, March, April,
> May, June, July, August, September, October". Here both the message and the
> month parameters are worng. On the server however this is done as per the
> documentation, but the passed in month is not localized, but picked up from
> the internal _monthMap map containing the months as "jan", "feb""dec" .
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (TRINIDAD-2485) Some attribute behaviors in tr:validateDateRestriction donot match their documentation
Ashwin Prabhu created TRINIDAD-2485:
---
Summary: Some attribute behaviors in tr:validateDateRestriction
donot match their documentation
Key: TRINIDAD-2485
URL: https://issues.apache.org/jira/browse/TRINIDAD-2485
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Affects Versions: 2.1.0-core
Reporter: Ashwin Prabhu
There are several issues in tr:validateDateRestriction. Here's a attribute-wise
list of problems which need to be fixed:
Attribute: invalidDays
The start and end dates passed into the method getDateList of DateListProvider
needs to be 24 hour wide. Currently the same date is passed for start and end
range, defeating the purpose of haveing 2 parameters. The current arrangement
works only if DateListProvider strictly goes by the date part and ignores the
time component in the start and end range.
The documentation of DateListProvider has this:
rangeStart - The start of the range for which dates are being requested.
rangeEnd - The end of the range for which dates are being requested.
Although not literallly mentioned, the implicit messaging of the parmater
description suggests the time part of the date range cannot be ignored.
Attribute: messageDetailInvalidDaysOfWeek
The documentation of message parameters states this:
{0} the label that identifies the component
{1} value entered by the user
{2} the invalid weekday
Currently the values passed as 3rd parameter ({2}) on the client contains a
list of all the days of the week, but for the user selected week. This behavior
is wrong as per the documentation. To see this behavior in acion please visit
http://example.irian.at/trinidad-demo/faces/convertValidate/dateRestrictionValidate.jspx
and select any monday in the 3rd input Date. You will see a error message
"Enter a date that is on one of the following days: Tuesday, Wednesday,
Thursday, Friday, Saturday, Sunday". Here both the message and the week-day
parameters are worng. On the server however this is done as per the
documentation, but the passed in weekday is not localized, but picked up from
the internal _dayMap map containing the week days as "sun", "mon""sat" .
To summarize,
The client validator needs to pass in parameters as per the documentation.
The server validator needs to localize the substituted week days.
THe message bundle string is currently "Enter a date that falls on one of the
following days: {0}" also needs to be changed to match the intention in the tag
document.
Attribute: messageDetailInvalidMonths
The documentation of message parameters states this:
{0} the label that identifies the component
{1} value entered by the user
{2} the invalid month
Currently the values passed as 3rd parameter ({2}) on the client contains a
list of all the months of the year, but for the user selected month. This
behavior is wrong as per the documentation. To see this behavior in acion
please visit
http://example.irian.at/trinidad-demo/faces/convertValidate/dateRestrictionValidate.jspx
and select any day in November in the 2rd input Date. You will see a error
message "November/December dates are not allowed here!
Enter a date in one of the following months: January, February, March, April,
May, June, July, August, September, October". Here both the message and the
month parameters are worng. On the server however this is done as per the
documentation, but the passed in month is not localized, but picked up from the
internal _monthMap map containing the months as "jan", "feb""dec" .
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TRINIDAD-2470) GenericConverterFactory needs to throw TypeConversionException in response to exceptions during conversion
[
https://issues.apache.org/jira/browse/TRINIDAD-2470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ashwin Prabhu updated TRINIDAD-2470:
Status: Patch Available (was: Open)
> GenericConverterFactory needs to throw TypeConversionException in response to
> exceptions during conversion
> --
>
> Key: TRINIDAD-2470
> URL: https://issues.apache.org/jira/browse/TRINIDAD-2470
> Project: MyFaces Trinidad
> Issue Type: Bug
> Components: Components
>Affects Versions: 2.1.0-core
> Environment: N/A
>Reporter: Ashwin Prabhu
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> The convert implementation in GenericConverterFactory has the following code:
> TypeConverter converter = getConverter(source.getClass(), targetType);
> if (converter != null)
> {
> return converter.convert(source, targetType);
> }
> throw new TypeConversionException(source, targetType);
> In addition to throwing TypeConversionException for missing converters, the
> above code needs to capture and re-throw any exception resulting during the
> conversion as TypeConversionException for the caller to handle them.
> Currently exceptions during the type conversion stage, unless they are
> ConverterExceptions remain unhandeled and cause PPR errors
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (TRINIDAD-2470) GenericConverterFactory needs to throw TypeConversionException in response to exceptions during conversion
Ashwin Prabhu created TRINIDAD-2470:
---
Summary: GenericConverterFactory needs to throw
TypeConversionException in response to exceptions during conversion
Key: TRINIDAD-2470
URL: https://issues.apache.org/jira/browse/TRINIDAD-2470
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Affects Versions: 2.1.0-core
Environment: N/A
Reporter: Ashwin Prabhu
The convert implementation in GenericConverterFactory has the following code:
TypeConverter converter = getConverter(source.getClass(), targetType);
if (converter != null)
{
return converter.convert(source, targetType);
}
throw new TypeConversionException(source, targetType);
In addition to throwing TypeConversionException for missing converters, the
above code needs to capture and re-throw any exception resulting during the
conversion as TypeConversionException for the caller to handle them.
Currently exceptions during the type conversion stage, unless they are
ConverterExceptions remain unhandeled and cause PPR errors
--
This message was sent by Atlassian JIRA
(v6.2#6252)
