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
