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 <robe...@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-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
