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]
