This is something I've been meaning to look at as well. I'd like to check what I've done for my client to see what I had to hack to accomplish this, to ensure that we don't go through a couple of cycles of this. I'm working for that client tomorrow, so I'll document that's needed then.
I think the entire approach needs to be a bit more pluggable (though decorating the service is also an option). On Wed, Dec 2, 2009 at 12:59 PM, Igor Drobiazko <[email protected]> wrote: > I would like to fix TAP5-915 and have to make ComponentMessagesSource a part > of the public API. I know we should be reluctant to move services from > internal packages but this feature is a must. Tapestry allows you to > override almost every part of the framework, but not the message catalog of > the components. Do you have any objections? > > The idea is to provide a mapped configuration for the service in which a > component class is mapped to a path. In the following example the message > catalog of DateField is obtained from foo/bar/baz and not from > /org/apache/tapestry5/corelib/components > > public void > contributeComponentMessagesSource(MappedConfiguration<Class,String> > configuration) > { > configuration.add(DateField.class, "/foo/bar/baz"); > } > > -- > Best regards, > > Igor Drobiazko > http://tapestry5.de/blog > -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
