You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@tapestry.apache.org by "Igor Drobiazko (JIRA)" <ji...@apache.org> on 2009/05/28 08:33:45 UTC

[jira] Commented: (TAP5-725) Last translator in configuration becomes default translator

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

Igor Drobiazko commented on TAP5-725:
-------------------------------------

This is an expected behavior because you override the mapping String <-> StringTranslator by String <-> TrimTranslator.
You cannot define tow different translators for a single field type. 

Your would your proposal match an appropriate translator for a field? Would you use the name of the page property to match the translator? This will not work if you have more than 2 fields of the same type. 

You are misusing the translators. You should use Validators instead. I think we can close the issue. 

> 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: 5.1.0.5
>            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.