You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Łukasz Jazgar <lu...@gmail.com> on 2009/05/28 12:52:58 UTC
Last translator in configuration becomes default translator
Hi,
I have put an issue to JIRA regarding using translators.
https://issues.apache.org/jira/browse/TAP5-725
For me it was obvious bug, so I've put it to JIRA first, but now Igor
Drobiazko makes me doubtful, if I understand correctly concept of
translators, so I would like to ask wider group of tapestry users, what
do you think about it.
Regards
Lukasz
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Last translator in configuration becomes default translator
Posted by Lukasz Jazgar <lu...@gmail.com>.
2009/5/31 Robert Zeigler <ro...@scazdl.org>:
> So, you're suggesting that a translator named, eg, "StringTranslator" would
> be the default for strings, "IntegerTranslator" for integers, and so forth.
> It could be done.
Yes, but Translator name property should be meaningful, not class name
of Translator. So, "string" would be default for java.lang.String,
"integer" for Integer and so forth.
Lukasz
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Last translator in configuration becomes default translator
Posted by Robert Zeigler <ro...@scazdl.org>.
So, you're suggesting that a translator named, eg, "StringTranslator"
would be the default for strings, "IntegerTranslator" for integers,
and so forth.
It could be done.
As for people relying on the current, unspecified, behavior, that's
just plain wrong, because there's absolutely no guarantee that their
contribution will, in fact, be the last contribution; the
configuration is unordered, after all.
Your solution would work, but... it still feels like a kludge to me.
I'm going to take a look at the commit logs to see if I can determine
why TranslatorDefaultSource was merged into TranslatorSource.
Robert
On May 29, 2009, at 5/296:07 PM , Lukasz Jazgar wrote:
> 2009/5/29 Robert Zeigler <ro...@scazdl.org>:
>> Certainly, your use-case would be supported if the configuration were
>> ordered, b/c you could order your contribution in such a way that the
>> default contribution isn't overridden, the way it is now.
>
> Yes, then I could add new translators before built-in one. But it
> doesn't remove foolish, nowhere written rule: "Last translator of
> given type is default translator". It would be still bad design.
> Appropriate solution is to create 2 intependent mappings managed by
> TranslatorSource:
> 1. name -> Translator - concerning all translators
> 2. type -> Translator - concerning only default translators
>
> The problem is, TranslatorSource receives only one simple list as
> configuration. There is no place for mapping 2.
> But ....
>
>> But changing the
>> configuration to ordered would mark a change to a public service...
>> not
>> going to happen.
>
> ... in JIRA issue (TAP5-725), I've proposed solution basing on using
> name of translator to define mapping 2.
> It doesn't need of changing interface of TranslatorSource. Only
> supplementing comments is required:
> "Translators, which name matches to name of type, which they work on
> (=Translator.getType()), are default for the type. They are used
> automatically, if there isn't specified translate parameter."
>
> This little change of specification and behaviour of TranslatorSource
> shouldn't have any unfavourable influence on existing applications.
> There is danger in only one case: If somebody utilized unspecified
> behaviour of current TS to override built-in default translator by
> translator with different, not type-like name.
>
>>
>> To answer question 3: no, not best practice, but I think
>> TranslatorSource
>> wasn't really intended to have multiple translators contributed for
>> the
>> exact same class-type, so... *shrug*.
>
> I think, original concept of translators assumed existance of multiple
> translators working on same type.
> In Tapestry 4, as I remember, it was possible.
> As I see in history of T5 sources, I suppose it was possible also in
> T5 before 07.02.2008. There were two separate services:
> TranslatorSource and TranslatorDefaultSource. Each of them managed one
> of mappings I mention before.
> I'm interesting, why Howard (?) decided to merge these two services to
> one, removing possibility of contributing alternative translators.
>
> Another interesting point. In Tapestry 4, there was possibility to
> pass parameters to translator eg.
> "translator:date,pattern=MM-dd-yyyy". It was very useful.
> Today, there are no parameters, even there are no DateTranslator. :(
>
> I know, we can write methods handling events onParseClient and
> onToClient. This is very fine functionality, but more suitable for
> specific, one-time-use translations. For common and repeatedly used
> translations, translators and template-level declarations of using
> them are more convenient.
>
>>
>> You know, though... you /could/ contribute your translator as a
>> translator
>> for CharSequence. Then it will still be available from the
>> TranslatorSource
>> via its name, and hence via the translate binding prefix, but the
>> default
>> String translator will be used for all strings where you don't
>> specify a
>> translator directly, since String is the more specific type.
>
> I know, there are a lot of possible work-arounds. That's beautiful in
> Tapestry. :)
>
> Regards
> Lukasz
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Last translator in configuration becomes default translator
Posted by Lukasz Jazgar <lu...@gmail.com>.
2009/5/29 Robert Zeigler <ro...@scazdl.org>:
> Certainly, your use-case would be supported if the configuration were
> ordered, b/c you could order your contribution in such a way that the
> default contribution isn't overridden, the way it is now.
Yes, then I could add new translators before built-in one. But it
doesn't remove foolish, nowhere written rule: "Last translator of
given type is default translator". It would be still bad design.
Appropriate solution is to create 2 intependent mappings managed by
TranslatorSource:
1. name -> Translator - concerning all translators
2. type -> Translator - concerning only default translators
The problem is, TranslatorSource receives only one simple list as
configuration. There is no place for mapping 2.
But ....
> But changing the
> configuration to ordered would mark a change to a public service... not
> going to happen.
... in JIRA issue (TAP5-725), I've proposed solution basing on using
name of translator to define mapping 2.
It doesn't need of changing interface of TranslatorSource. Only
supplementing comments is required:
"Translators, which name matches to name of type, which they work on
(=Translator.getType()), are default for the type. They are used
automatically, if there isn't specified translate parameter."
This little change of specification and behaviour of TranslatorSource
shouldn't have any unfavourable influence on existing applications.
There is danger in only one case: If somebody utilized unspecified
behaviour of current TS to override built-in default translator by
translator with different, not type-like name.
>
> To answer question 3: no, not best practice, but I think TranslatorSource
> wasn't really intended to have multiple translators contributed for the
> exact same class-type, so... *shrug*.
I think, original concept of translators assumed existance of multiple
translators working on same type.
In Tapestry 4, as I remember, it was possible.
As I see in history of T5 sources, I suppose it was possible also in
T5 before 07.02.2008. There were two separate services:
TranslatorSource and TranslatorDefaultSource. Each of them managed one
of mappings I mention before.
I'm interesting, why Howard (?) decided to merge these two services to
one, removing possibility of contributing alternative translators.
Another interesting point. In Tapestry 4, there was possibility to
pass parameters to translator eg.
"translator:date,pattern=MM-dd-yyyy". It was very useful.
Today, there are no parameters, even there are no DateTranslator. :(
I know, we can write methods handling events onParseClient and
onToClient. This is very fine functionality, but more suitable for
specific, one-time-use translations. For common and repeatedly used
translations, translators and template-level declarations of using
them are more convenient.
>
> You know, though... you /could/ contribute your translator as a translator
> for CharSequence. Then it will still be available from the TranslatorSource
> via its name, and hence via the translate binding prefix, but the default
> String translator will be used for all strings where you don't specify a
> translator directly, since String is the more specific type.
I know, there are a lot of possible work-arounds. That's beautiful in
Tapestry. :)
Regards
Lukasz
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Last translator in configuration becomes default translator
Posted by Robert Zeigler <ro...@scazdl.org>.
Ok, I was digging through the source a bit on this, and I see your
point.
It's evident from the implementation that contributing multiple
translators per class-type is unsupported, since the class-based
lookup strategy depends on a map w/ the class as the key.
But the documentation for the service interface doesn't state that.
Certainly, your use-case would be supported if the configuration were
ordered, b/c you could order your contribution in such a way that the
default contribution isn't overridden, the way it is now. But
changing the configuration to ordered would mark a change to a public
service... not going to happen.
To answer question 3: no, not best practice, but I think
TranslatorSource wasn't really intended to have multiple translators
contributed for the exact same class-type, so... *shrug*.
Perhaps the service should throw an exception when it detects that
situation to make it clear that it isn't intended.
You know, though... you /could/ contribute your translator as a
translator for CharSequence. Then it will still be available from the
TranslatorSource via its name, and hence via the translate binding
prefix, but the default String translator will be used for all strings
where you don't specify a translator directly, since String is the
more specific type.
Robert
On May 28, 2009, at 5/283:50 PM , Lukasz Jazgar wrote:
> 2009/5/28 Robert Zeigler <ro...@scazdl.org>:
>> So don't contribute your translator.
>> Instead, supply the translator directly to the translator
>> parameter, and
>> construct it yourself?
>> The TranslatorSource is meant to be exactly that: a general source
>> for
>> translators, so you don't have to constantly specify them yourself.
>> But if you have specific needs for specific fields, you should
>> manually
>> supply your custom translator to those fields (and /not/ contribute
>> it to
>> TranslatorSource).
>
> Thanks. Good solution.
> But generally, I am not looking for workaround. I would like my
> favorite framework be better and more useful. :)
>
> Question is: Does current behaviour of TranslatorSource is intentional
> or not? Is my JIRA issue justifiable?
>
> Other questions:
> * If TranslatorSource is correct and expected behaviour is that "You
> cannot define two different translators for a single field type." as
> Igor has written, what is binding prefix "translate:" for? It seems to
> be completely useless, if I cannot contribute alternative translators
> to TranslatorSource.
>
> * Is it good practice in Tapestry to create service configurable by
> unordered collection, which behaviour depends on order? Current
> TranslatorSource is such a service.
>
> Regards
> Lukasz
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Last translator in configuration becomes default translator
Posted by Lukasz Jazgar <lu...@gmail.com>.
2009/5/28 Robert Zeigler <ro...@scazdl.org>:
> So don't contribute your translator.
> Instead, supply the translator directly to the translator parameter, and
> construct it yourself?
> The TranslatorSource is meant to be exactly that: a general source for
> translators, so you don't have to constantly specify them yourself.
> But if you have specific needs for specific fields, you should manually
> supply your custom translator to those fields (and /not/ contribute it to
> TranslatorSource).
Thanks. Good solution.
But generally, I am not looking for workaround. I would like my
favorite framework be better and more useful. :)
Question is: Does current behaviour of TranslatorSource is intentional
or not? Is my JIRA issue justifiable?
Other questions:
* If TranslatorSource is correct and expected behaviour is that "You
cannot define two different translators for a single field type." as
Igor has written, what is binding prefix "translate:" for? It seems to
be completely useless, if I cannot contribute alternative translators
to TranslatorSource.
* Is it good practice in Tapestry to create service configurable by
unordered collection, which behaviour depends on order? Current
TranslatorSource is such a service.
Regards
Lukasz
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Last translator in configuration becomes default translator
Posted by Robert Zeigler <ro...@scazdl.org>.
So don't contribute your translator.
Instead, supply the translator directly to the translator parameter,
and construct it yourself?
The TranslatorSource is meant to be exactly that: a general source for
translators, so you don't have to constantly specify them yourself.
But if you have specific needs for specific fields, you should
manually supply your custom translator to those fields (and /not/
contribute it to TranslatorSource).
Robert
On May 28, 2009, at 5/289:21 AM , Lukasz Jazgar wrote:
> 2009/5/28 Thiago H. de Paula Figueiredo <th...@gmail.com>:
>> 2009/5/28 Łukasz Jazgar <lu...@gmail.com>:
>>
>> As Igor pointed out, it's not a bug, it's how things are. You can't
>> provide more than one default translator for a given type.
>
> I don't want to provide more than one DEFAULT translator. Of course
> more than one default translator for one type has completly no sense.
> I want only to provide translator which translates to/from given type,
> not default.
>
>> On the
>> other hand, you can provide a translator using the translate
>> parameter
>> of TextField, so the default one is not used in this case.
>
> The probem is translator which I provide becomes default translator
> and all TextField values are translated by him, regardless of
> translate parameter.
>
> Lukasz
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Last translator in configuration becomes default translator
Posted by Lukasz Jazgar <lu...@gmail.com>.
2009/5/28 Thiago H. de Paula Figueiredo <th...@gmail.com>:
> 2009/5/28 Łukasz Jazgar <lu...@gmail.com>:
>
> As Igor pointed out, it's not a bug, it's how things are. You can't
> provide more than one default translator for a given type.
I don't want to provide more than one DEFAULT translator. Of course
more than one default translator for one type has completly no sense.
I want only to provide translator which translates to/from given type,
not default.
> On the
> other hand, you can provide a translator using the translate parameter
> of TextField, so the default one is not used in this case.
The probem is translator which I provide becomes default translator
and all TextField values are translated by him, regardless of
translate parameter.
Lukasz
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Last translator in configuration becomes default translator
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
2009/5/28 Łukasz Jazgar <lu...@gmail.com>:
> Hi,
Hi!
> I have put an issue to JIRA regarding using translators.
> https://issues.apache.org/jira/browse/TAP5-725
> For me it was obvious bug, so I've put it to JIRA first, but now Igor
> Drobiazko makes me doubtful, if I understand correctly concept of
> translators, so I would like to ask wider group of tapestry users, what
> do you think about it.
As Igor pointed out, it's not a bug, it's how things are. You can't
provide more than one default translator for a given type. On the
other hand, you can provide a translator using the translate parameter
of TextField, so the default one is not used in this case.
--
Thiago
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org