You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by Igor Drobiazko <ig...@gmail.com> on 2009/12/02 21:59:05 UTC
ComponentMessagesSource to become public API
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
Re: ComponentMessagesSource to become public API
Posted by Robin Komiwes <od...@gmail.com>.
I had this problem before and I had to hack some internals services to make
it works.
I'm definitely OK to make this API public.
On Wed, Dec 2, 2009 at 9:59 PM, Igor Drobiazko <ig...@gmail.com>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
>
Re: ComponentMessagesSource to become public API
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Wed, 02 Dec 2009 20:54:09 -0200, Howard Lewis Ship <hl...@gmail.com>
escreveu:
> I think the entire approach needs to be a bit more pluggable (though
> decorating the service is also an option).
Service decoration in Tapestry-IoC is very powerful. Once I was in a hurry
and needed to override a service implementation. I tried using
ServiceOverride, but I got the "service depends on itself" exception. Then
I just added a decorate method, instantiated the new service
implementation and returned it, completely ignoring the original
implementation and not doing any decoration. Works like a charm. :)
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, software architect and developer, Ars Machina Tecnologia da
Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: ComponentMessagesSource to become public API
Posted by Igor Drobiazko <ig...@gmail.com>.
After thinking about it once again I prefer this option too. It is more
convenient for a user to provide messages for a component in the catalog of
the containing page, inject the Messages service and bind it to component's
message parameter.
The default of the message parameter of a component is the injected Messages
service which represents the component's messages catalog.
On Sat, Dec 12, 2009 at 3:04 AM, Howard Lewis Ship <hl...@gmail.com> wrote:
> I favor the option of extending the components with new parameters to
> specify the message catalog in which to look for messages, defaulting
> to searching their container's message catalog (as today). However,
> that logic is not centrally located I don't think.
>
>
> On Fri, Dec 11, 2009 at 5:52 AM, Massimo Lusetti <ml...@gmail.com>
> wrote:
> > On Wed, Dec 9, 2009 at 10:31 PM, Igor Drobiazko
> > <ig...@gmail.com> wrote:
> >
> >> So, what is the consensus on this issue?
> >
> > My proposal is to let T5 traverse the component structure from inner
> > to outer most component and let the last matching win.
> >
> > This breaks existing behavior but i think that due to the current
> > nature of the message catalog (and the way it behave) there will be
> > not so many clients that will be broken since most of the use case are
> > messages-per-components.
> > Let's say now every component has only it own message catalog and it
> > will not suffer at all if T5 will search the components structure
> > upwards for overwrites. Doesn't?
> >
> > I think we could poll the user base for answers in this particular case.
> >
> > 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
Re: ComponentMessagesSource to become public API
Posted by Howard Lewis Ship <hl...@gmail.com>.
I favor the option of extending the components with new parameters to
specify the message catalog in which to look for messages, defaulting
to searching their container's message catalog (as today). However,
that logic is not centrally located I don't think.
On Fri, Dec 11, 2009 at 5:52 AM, Massimo Lusetti <ml...@gmail.com> wrote:
> On Wed, Dec 9, 2009 at 10:31 PM, Igor Drobiazko
> <ig...@gmail.com> wrote:
>
>> So, what is the consensus on this issue?
>
> My proposal is to let T5 traverse the component structure from inner
> to outer most component and let the last matching win.
>
> This breaks existing behavior but i think that due to the current
> nature of the message catalog (and the way it behave) there will be
> not so many clients that will be broken since most of the use case are
> messages-per-components.
> Let's say now every component has only it own message catalog and it
> will not suffer at all if T5 will search the components structure
> upwards for overwrites. Doesn't?
>
> I think we could poll the user base for answers in this particular case.
>
> 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
Re: ComponentMessagesSource to become public API
Posted by Massimo Lusetti <ml...@gmail.com>.
On Wed, Dec 9, 2009 at 10:31 PM, Igor Drobiazko
<ig...@gmail.com> wrote:
> So, what is the consensus on this issue?
My proposal is to let T5 traverse the component structure from inner
to outer most component and let the last matching win.
This breaks existing behavior but i think that due to the current
nature of the message catalog (and the way it behave) there will be
not so many clients that will be broken since most of the use case are
messages-per-components.
Let's say now every component has only it own message catalog and it
will not suffer at all if T5 will search the components structure
upwards for overwrites. Doesn't?
I think we could poll the user base for answers in this particular case.
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
Re: ComponentMessagesSource to become public API
Posted by Igor Drobiazko <ig...@gmail.com>.
So, what is the consensus on this issue?
Re: ComponentMessagesSource to become public API
Posted by Igor Drobiazko <ig...@gmail.com>.
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 <ro...@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 <hl...@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 <ml...@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
Re: ComponentMessagesSource to become public API
Posted by Robert Zeigler <ro...@scazdl.org>.
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 <hl...@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 <ml...@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
Re: ComponentMessagesSource to become public API
Posted by Igor Drobiazko <ig...@gmail.com>.
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 <hl...@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 <ml...@gmail.com>
> wrote:
> > On Thu, Dec 3, 2009 at 7:52 AM, Igor Drobiazko <ig...@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
Re: ComponentMessagesSource to become public API
Posted by Massimo Lusetti <ml...@gmail.com>.
On Sun, Dec 6, 2009 at 9:02 PM, Howard Lewis Ship <hl...@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).
Yep, that should be the solution if not limited to the containing page
but extended to all "containing components".
Do you like a Jira issue about this one?
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
Re: ComponentMessagesSource to become public API
Posted by Howard Lewis Ship <hl...@gmail.com>.
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 <ml...@gmail.com> wrote:
> On Thu, Dec 3, 2009 at 7:52 AM, Igor Drobiazko <ig...@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
Re: ComponentMessagesSource to become public API
Posted by Massimo Lusetti <ml...@gmail.com>.
On Fri, Dec 4, 2009 at 7:37 AM, Igor Drobiazko <ig...@gmail.com> wrote:
> This would be a nice addition but does not solve the problem. Components are
> reusable and their message catalog should be reusable too. I don't want to
> provide messages for a component in every page using it. What is needed is
> just a "redirect" to another package to look for message catalog.
As you said it would be an addition so an extension like system...
> Now the messages are searched in a low-specific to a most-specific order. If
> a component message catalog contains an entry for a particular key the
> application wide catalog will be never considered. So you don't have any
> chance to override existing translations of a component. For backward
> compatibility reasons this behavior should not be changed.
Well even i perfectly understand the "backward compatibilty" shield
effect i think that some thoughts should be deserved to such an
option.
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
Re: ComponentMessagesSource to become public API
Posted by Igor Drobiazko <ig...@gmail.com>.
>
> 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.
>
This would be a nice addition but does not solve the problem. Components are
reusable and their message catalog should be reusable too. I don't want to
provide messages for a component in every page using it. What is needed is
just a "redirect" to another package to look for message 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.
>
Now the messages are searched in a low-specific to a most-specific order. If
a component message catalog contains an entry for a particular key the
application wide catalog will be never considered. So you don't have any
chance to override existing translations of a component. For backward
compatibility reasons this behavior should not be changed.
>
> 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
>
>
--
Best regards,
Igor Drobiazko
http://tapestry5.de/blog
Re: ComponentMessagesSource to become public API
Posted by Massimo Lusetti <ml...@gmail.com>.
On Thu, Dec 3, 2009 at 7:52 AM, Igor Drobiazko <ig...@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
Re: ComponentMessagesSource to become public API
Posted by Igor Drobiazko <ig...@gmail.com>.
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.
On Wed, Dec 2, 2009 at 11:54 PM, Howard Lewis Ship <hl...@gmail.com> wrote:
> 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
> <ig...@gmail.com> 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: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
Best regards,
Igor Drobiazko
http://tapestry5.de/blog
Re: ComponentMessagesSource to become public API
Posted by Howard Lewis Ship <hl...@gmail.com>.
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
<ig...@gmail.com> 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: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org