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
