Hi Paul, I share your view on this topic. Some time ago, I was struggling a bit with trying to control the precise formatting of numeric fields, and I eventually had to create a new translator with a new binding. The toClient() method of the translator takes care of the required formatting specified by the binding expression. I wasn't totally happy with the solution, but it has been working for me and I don't have time to look for alternatives. If you come up with a good solution, please share it. Thanks.
Benny On Thu, Dec 23, 2010 at 11:19 PM, Paul Stanton <p...@mapshed.com.au> wrote: > Thanks Bryan, > > Yes it seems this is some functionality that has been victim of some other > architectural concept. > > This is confusing and disappointing to me - I see it as a key facility that > should be provided by the framework since one of the key tasks (you could > argue "the key task") of web applications is to convert objects into strings > and back again. > > I see the role of formatters and translators intricately linked - otherwise > there is certain code repetition and therefore maintenance issues. Also, > constantly defining getter methods in components to make global formatters > available is hardly a good approach, and no better than extending a > 'BaseComponent' to access these properties. > > This could be solved with the old style "service" binding prefix which is > also gone from the implementation. > > If no one can tell me what existing tapestry concept I'm missing I may > spend some time seeing if I can write some code to get this going. > > Step one would be to create an object structure that makes it easy to > define an object that implements both Translator and Formatter. > > Step two would be to create a binding prefix to supply the appropriate > Translator/Formatter object to components, which would be registered in the > binding prefix by name. > > p. >
