tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jochen Kemnade (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (TAP5-1365) allow Translators to be registered by name and used as Formatters
Date Tue, 27 May 2014 07:20:50 GMT

     [ 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)

Mime
View raw message