tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Howard Lewis Ship" <hls...@gmail.com>
Subject Re: [T5] overriding application-wide message catalog location?
Date Tue, 10 Jun 2008 17:50:52 GMT
This could easly be addressed by introducing a new symbol for the path
to the application message catalog, which would allow an application
override.  Please add an issue to JIRA.

On Tue, Jun 10, 2008 at 1:44 AM, Neeme Praks <neeme@apache.org> wrote:
> Hi all,
>
> Tapestry5 is shaping up quite nicely, great work!
> As a result, I have chosen Tapestry 5 as the framework to build a new
> project on :-)
>
> Inevitably, there will be questions and here is mine:
>  Is there some way to override application-wide message catalog location?
> The default is WEB-INF/<appname>.properties
>
> Why would I want to do that? Well, historically we have used Spring Web-MVC
> for our applications and there we stored the application message catalog in
> WEB-INF/messages/messages.properties and I would like to keep that location
> unchanged. Easier for our translators.
>
> As far as I can see in the source code, this location is pretty much
> hardcoded? org.apache.tapestry.services.TapestryModule has:
>
>    public ComponentMessagesSource buildComponentMessagesSource(
>            @ContextProvider
>            AssetFactory contextAssetFactory,
>
>            @Inject
>            @Value("WEB-INF/${tapestry.app-name}.properties")
>            String appCatalog)
>    {
>        ComponentMessagesSourceImpl service = new
> ComponentMessagesSourceImpl(contextAssetFactory
>                .getRootResource(), appCatalog);
>
>        updateListenerHub.addUpdateListener(service);
>
>        return service;
>    }
>
> As this location is hardcoded, I guess I have two options:
> * patch Tapestry to make it configurable
> * override the definition of ComponentMessagesSource with my own
> implementation (or just my own configuration)
>
> I guess the first option is a long-term solution and second is a short-term
> solution?
>
> I'm willing to investigate the possibility for patching Tapestry (any
> pointers are very welcome), but at the same time, I would also like to
> implement the short-term solution to solve the issue at hand.
>
> While investigating the possibility to override, I came across the
> following.
> On page http://tapestry.apache.org/tapestry5/tapestry-ioc/module.html
> it is written that:
> "Service ids must be unique; if another module contributes a service with
> the id "Indexer" (or any case variation thereof) a runtime exception will
> occur when the Registry is created."
>
> Does this mean that I cannot override the default ComponentMessagesSource
> service implementation?
>
> I hope I misunderstood something :-)
>
> And, while I'm already consuming airtime here: how can I override the
> default tapestry configuration mechanism with my own? So instead of taking
> parameters from web.xml, I can implement my own way of loading them (e.g.
> from properties file, from DB, etc).
>
> Rgds,
> Neeme
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>



-- 
Howard M. Lewis Ship

Creator Apache Tapestry and Apache HiveMind

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org


Mime
View raw message