The bottom-up search for messages is how Tapestry is looking for translations now. But the problem is that we are talking about replacing existing translation. Tapestry stops searching when the component's message catalog contains a particular key. You need somehow to tell Tapestry to continue searching even if the key is already found. So what is the most elegant way to do it?
Howard suggested to add a parameter of the types Messages to all the components, right? In this case a user is responsible to for constructing the message instance that is bound into the component's parameter. What I'm proposing is the similar solution how ValidationMessagesSource is working. You just override the path to the message catalog of the component. That's it. On Tue, Dec 8, 2009 at 5:04 AM, Robert Zeigler <[email protected]> wrote: > Unless you put the definitions in your application's app.properties, right? > Then you still have to provide the custom resources component-by-component, > but the translations go in a single place. > > Robert > > > On Dec 7, 2009, at 12/75:53 PM , Igor Drobiazko wrote: > > Hm, what about components that are used in several pages? In this case I >> have to repeat the translations again and again. >> >> On Sun, Dec 6, 2009 at 9:02 PM, Howard Lewis Ship <[email protected]> >> wrote: >> >> Perhaps what's really needed is for components to more frequently have >>> a parameter used to override its internal messages with a new messages >>> object (presumably form the page). >>> >>> On Thu, Dec 3, 2009 at 8:52 AM, Massimo Lusetti <[email protected]> >>> wrote: >>> >>>> On Thu, Dec 3, 2009 at 7:52 AM, Igor Drobiazko < >>>> [email protected]> >>>> >>> wrote: >>> >>>> >>>> I accompiished this by a service named ComponentMessagesOverride. The >>>>> >>>> mapped >>> >>>> configuration of the service is used to contribute new paths for >>>>> >>>> component >>> >>>> message catalogs. This service is used in an advise method to override >>>>> >>>> the >>> >>>> result of ComponentMessagesSource#getMessages. This temporary hack is ok >>>>> >>>> for >>> >>>> an application but what is the benefit to do it in tapestry-core? We can >>>>> change the implementation of ComponentMessagesSource directly. >>>>> >>>> >>>> While here I would like to pose to your attention a use case where i >>>> found myself repeatedly. >>>> >>>> It happens that I produce a "common" components (like a series of >>>> Submit components acting togheter) where i want the pages that use it >>>> to provide the "messages" for labels. So this could be accomplish by >>>> extending the inheritance of the message catalog from components to >>>> pages that include the components (or other components as well) to >>>> application wide catalog. >>>> >>>> So for instance a components could provide defaults labels but pages >>>> are given the opportunity to override it while leave the "application >>>> wide" message catalog to have the last word on it. >>>> >>>> Does it sounds reasonable? >>>> >>>> Cheers >>>> -- >>>> Massimo >>>> http://meridio.blogspot.com >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>>> >>>> >>> >>> >>> -- >>> 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] >>> >>> >>> >> >> -- >> Best regards, >> >> Igor Drobiazko >> http://tapestry5.de/blog >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- Best regards, Igor Drobiazko http://tapestry5.de/blog
