tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Igor Drobiazko <igor.drobia...@gmail.com>
Subject Re: ComponentMessagesSource to become public API
Date Tue, 08 Dec 2009 07:35:48 GMT
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 <robertz@scazdl.org> 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 <hlship@gmail.com>
>> 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 <mlusetti@gmail.com>
>>> wrote:
>>>
>>>> On Thu, Dec 3, 2009 at 7:52 AM, Igor Drobiazko <
>>>> igor.drobiazko@gmail.com>
>>>>
>>> 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: dev-unsubscribe@tapestry.apache.org
>>>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> 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: dev-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>>
>>>
>>>
>>
>> --
>> Best regards,
>>
>> Igor Drobiazko
>> http://tapestry5.de/blog
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>


-- 
Best regards,

Igor Drobiazko
http://tapestry5.de/blog

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message