tapestry-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geoff Callender (JIRA)" <j...@apache.org>
Subject [jira] Commented: (TAP5-725) Last translator in configuration becomes default translator
Date Fri, 08 Jan 2010 13:58:54 GMT

    [ https://issues.apache.org/jira/browse/TAP5-725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12798017#action_12798017

Geoff Callender commented on TAP5-725:

I've just had the same issue when I tried to implement a PhoneNumberTranslator but as described
above it overrode the StringTranslator globally. 

The aim of my PhoneNumberTranslator is to parse all sorts of client input, removing spaces,
hyphens, brackets etc. into a standard format for saving to the DB. On output it formats the
phone number based on the rules of the country, adding spaces etc. as required. IMHO this
is the role of a Translator, not a Validator.

As a hack workaround, I followed Robert Zeigler's suggestion to register my translator as
a CharSequence translator rather than a String translator. It works, but it's clearly a hack.
See http://thread.gmane.org/gmane.comp.java.tapestry.user/72777/focus=72821

I think we should be able to contribute any number of translators without fear of them globally
overriding any others.

> Last translator in configuration becomes default translator
> -----------------------------------------------------------
>                 Key: TAP5-725
>                 URL: https://issues.apache.org/jira/browse/TAP5-725
>             Project: Tapestry 5
>          Issue Type: Bug
>          Components: tapestry-core
>    Affects Versions:
>            Reporter: Lukasz Jazgar
>         Attachments: TrimTranslator.java
> I've created simple translator TrimTranslator, which works on String fields. It is same
as StringTranslator. Only difference is it removes all white spaces at beginning and end of
string. I will attach java source file of it.
> When I've contributed this translator to TranslatorSource service, new translator became
default for type String. Every string value incoming from client is now trimmed. It's wrong.
I expect new translator will work only when I explicitly declare it for form field component.
> As I see, historically (more than 1 year ago) there was 2 distinct services TranslatorSource
and TranslatorDefaultSource. It was clear. 
> Later they was joined to one. Why? Current TranslatorSource works fine only if there
is one translator for every type or we want to override default translator. There is no possibility
to create new alternative translators. 
> Proposal of resolution:
> Maybe default translators for type should be distinguished by it's name property, which
is unique, not only type?
> Default translators should have name same as name of type. So, "string" is default for
java.lang.String, "boolean" is default for java.lang.Boolean, and so on. Any other like "trim"
or "yesno" (example in jumpstart app) should need explicit declaration.
> It boils down to replacing in constructor of TranslatorSourceImpl:
> typeToTranslator.put(t.getType(), t);
> with:
> if (t.getType().getSimpleName().equalsIgnoreCase(t.getName()) {
>             typeToTranslator.put(t.getType(), t);
> }

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message