I replace the standard InitializerSRL with MYInitializerSRL so there's no efficiency problem. It seems better to me to replace the standard InitializerSRL rather than add an extra SRL but that's just me.
Thanks for your answers, everything is more clear now. On Mon, Jun 24, 2013 at 10:35 AM, Martin Grigorov <[email protected]>wrote: > On Mon, Jun 24, 2013 at 10:29 AM, Marios Skounakis <[email protected]> > wrote: > > > Martin, > > > > What I meant is that now I have my own > > class MyInitializerStringResourceLoader extends > > InitializerStringResourceLoader > > > > and its constructor calls > > > > super(sort(initializers)); > > > > and sort() puts my own Initializer first in the initializers list. Is > this > > not safe? It does seem to work (whereas before it wasn't working). > > > > > I understood what you said. > I just explained why it didn't work the first time. > > Your solution is a "custom ISRL". It is a bit inefficient but it is > working. > It is inefficient because now your application class uses both > InitializerSRL and MyInitializerSRL, and both of them keep a list of same > initializers. > MyISRL doesn't need the list. It needs to use just the class of your > IInitializer implementation. See the code of InitializerSRL to realize what > you can cut from your MyISRL. > > > > > > On Mon, Jun 24, 2013 at 10:20 AM, Martin Grigorov <[email protected] > > >wrote: > > > > > The order of the initializers depends on the order of the jars in the > > > classpath. > > > Depending on the order is not recommended. > > > > > > I think Cedric's idea was to roll your own ISRL that knows exactly > where > > is > > > your resource bundle and knows how to load it. > > > > > > > > > On Mon, Jun 24, 2013 at 10:16 AM, Marios Skounakis <[email protected]> > > > wrote: > > > > > > > Not sure if this is what you mean but in Application.init I replaced > > the > > > > InitializerStringResourceLoader in > > > > application.getResourceSettings().getStringResourceLoaders() with my > > own > > > > MyInitializerStringResourceLoader which resorts the initializers list > > and > > > > puts my own initializer in the first position. > > > > > > > > It works. > > > > > > > > Thanks > > > > > > > > > > > > On Mon, Jun 24, 2013 at 9:09 AM, Cedric Gatay <[email protected]> > > wrote: > > > > > > > > > Hi, > > > > > You can write your own IStringResourceLoader providing your set of > > > > > translations and register it in front of the list through the > > > > IInitializer > > > > > mechanism. > > > > > > > > > > Regards, > > > > > Le 24 juin 2013 07:12, "Marios Skounakis" <[email protected]> a > > écrit : > > > > > > > > > > > Hi all, > > > > > > > > > > > > I am developing a "framework" library with wicket components and > > > > utility > > > > > > classes that is intended to be reused in all wicket apps > developed > > by > > > > our > > > > > > company. I wish to override some of the standard wicket messages > > > (e.g. > > > > > > wicket-extensions datatable.no-records-found=No Records Found). > > > > > > > > > > > > I have created an Initializer class and a Initializer.properties > > file > > > > > with > > > > > > the overriden messages. However wicket seems to first load the > > > > > > wicket-extensions property file and then my own, perhaps due to > > their > > > > > > alphabetic order. > > > > > > > > > > > > Is there a way to specify the order in which Initilizers run? If > > not, > > > > is > > > > > > there another way to override some of the wicket messages in a > > place > > > > that > > > > > > can be reused across multiple applications (i.e. not in > > > > > > WicketApplication.properties or a component/page properties > file). > > > > > > > > > > > > Thanks > > > > > > Marios > > > > > > > > > > > > > > > > > > > > >
