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 <robe...@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-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
