[jira] [Updated] (TAP5-1365) allow Translators to be registered by name and used as Formatters

["Jochen Kemnade (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/TAP5-1365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jochen Kemnade updated TAP5-1365:
---------------------------------

    Labels: bulk-close-candidate  (was: )

This issue has been last updated about 1.5 years ago, has no assignee, affects an old version of Tapestry that is not actively developed anymore, and is therefore prone to be bulk-closed in the near future.

If the issue still persists with the most recent development preview of Tapestry (5.4-beta-6, which is available from Maven Central), please update it as soon as possible. In the case of a feature request, please discuss it with the Tapestry developer community on the dev@tapestry.apache.org mailing list first.


> allow Translators to be registered by name and used as Formatters
> -----------------------------------------------------------------
>
>                 Key: TAP5-1365
>                 URL: https://issues.apache.org/jira/browse/TAP5-1365
>             Project: Tapestry 5
>          Issue Type: Improvement
>    Affects Versions: 5.2
>            Reporter: Paul Stanton
>              Labels: bulk-close-candidate
>
> It's my understanding that a regression between version 5.1 and 5.2 meant that it is no longer possible to register translators by name (without some extra plumbing) via the 'translate' binding prefix.
> Instead you can override the default Translator for a particular type meaning you can have one translator per type.
> This means that the 'translate' binding prefix is perhaps redundant, since the translator could be selected by value type.
> I might be incorrect in my understanding but either way, I'd appreciate the discussion on the benefits of my suggested approach.
> What I suggest is at least a partial return to the old model whereby you could register a translator by name and for example have a 'date-long' translator and a 'date-short' translator co-exist, or a 'decimal-2dp' and a 'decimal-3dp' translator. you would then select the appropriate translator via the parameter binding
> <t:textfield value="myDecimal" translator="translate:decimal-2dp" />
> Secondly, since Translators are capable of converting objects to text, there should be no reason why they couldn't be re-used as formatters, so you could also use
> <t:output value="myDate" format="translate:date-long" />
> The inclusion of both of these features would allow a developer to create one set of Translators which are responsible for all object-to-text and text-to-object conversions throughout an application, thereby avoiding repetitive coding.



--
This message was sent by Atlassian JIRA
(v6.2#6252)