[
https://issues.apache.org/jira/browse/TAP5-725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12713927#action_12713927
]
Lukasz Jazgar 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.
Why?!
There is "translate" parameter in form fields components. What is it for, if I
can't choose translator from among few different?
Idea of translators, as I remember from Tapestry 4, assumes that you can write
translator and turn it on for chosen fields. How it can be done, if there is
only one translator for type?
For example, it could be written such translators,
For String:
trim - removing whitespaces at beginning and end (only for client->property
direction)
upper - making value uppercase (only for client->property direction)
lower - making value lowercase (only for client->property direction)
iban - IBAN - International Bank Account Number. For direction client->property
removing all whitespaces. For direction property->client, adding spaces after
each 4 digits.
For Double and Float:
fractionDigits=n- For direction client->property rounding number to have n
fraction digits. For opposite direction, formatting number by DecimalFormat
"##0.00"
And so on, and so on.
Year ago (before 07.02.2008), it was correct. There was 2 separate mappings:
1. type -> Translator - meaning "default translator for type", managed by
TranslatorDefaultSource
2. name ->Translator - used in case of using translate parameter, managed by
TranslatorSource
Now, both of them are managed by TranslatorSource, but there is no possibility
to change one without influence to the other.
> Your would your proposal match an appropriate translator for a field?
No. My proposal only assumes simple rule - default translator for type String
is that with name "string".
It is only idea, which comes to my brain, correcting this without changing API.
> You are misusing the translators. You should use Validators instead.
I disagree. Validators are to check constraints. What I want to do, is define
mapping between client view/input and model and this is work for Translators.
> 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.
