I also think that it is a good approach from the point of view of performance and memory management.
What is to add - there is not so much efforts to adopt existing one framework to this approach. Any thoughts what is the proper way to go? On 7/10/06, Alexey Petrenko <[EMAIL PROTECTED]> wrote:
Yep, it's an interesting idea. I like it! SY, Alexey 2006/7/10, Alexey Varlamov <[EMAIL PROTECTED]>: > Ilya, > > I'd also suggest you to look at > http://www.eclipse.org/eclipse/platform-core/documents/3.1/message_bundles.html . > It describes quite smart approach for using message bundles, we could > go in the similar direction. > > -- > Alexey Varlamov > > > 2006/7/10, Ilya Okomin <[EMAIL PROTECTED]>: > > Tim Ellison wrote: > > >Mikhail Loenko wrote: > > >> 2006/5/25, Tim Ellison <[EMAIL PROTECTED] >: > > >>> Mikhail Loenko wrote: > > >>> > We also agreed to put only internationalized messages and > > >>> > to have a single catalog by module. > > >>> > > >>> Yep, that's a good task for somebody who is looking for a simple way to > > >>> contribute to Harmony's classlibs. > > >>> > > >>> If anyone wants to volunteer then go for it -- I can help with guidance > > >>> if required. > > >>> > > >>> > Is there any way to meet all the agreements without rewriting the > > >>> > internationalization framework? > > >>> > > >>> I don't think we need to change the mechanism we use to get message > > >>> strings from resource catalogs, just split the single catalog up across > > >>> the modules. > > >> > > >> So we are splitting messages across the modules and than unite them back > > >> at build time, correct? > > > > > >Sorry for causing confusion, I was being too brief. > > > > > >I meant that the mechanism we currently have in LUNI (i.e. a resource > > >file of externalized strings and a helper class like Msg to load the > > >string and format it etc.) can be duplicated in each module that has > > >externalized strings e.g. for exception messages. Of course, each > > >module would only have its own messages. > > > > > >In this case the code is quite trivial so I don't see a big problem with > > >duplication. At runtime, each module is a self-contained JAR with it's > > >o.a.h.<foo>.internal.Msg and string catalog in the JAR file. > > > > > >Regards, > > >Tim > > > > > >-- > > > > > >Tim Ellison ( [EMAIL PROTECTED] ) > > >IBM Java technology centre, UK. > > > > > >--------------------------------------------------------------------- > > >Terms of use : http://incubator.apache.org/harmony/mailing.html > > >To unsubscribe, e-mail: [EMAIL PROTECTED] > > >For additional commands, e-mail: [EMAIL PROTECTED] > > > > Hello all! > > > > I'd like to be a volunteer for that. > > > > IMHO it's reasonable to use framework presented in luni module with some > > modifications. > > To avoid duplication of Msg class I'd suggest use slightly modified Msg > > class named let say > > o.a.h.luni.utils.ExtMsg. > > ExtMsg has the same methods as Msg, the difference is only these methods are > > non static, > > also specific external messages resource bundle will be initialized by name > > in the constructor. > > Each module will have class o.a.h.<module>.MsgUtils with static field 'msg' > > that is the instance of ExtMsg > > initialized with the name of the external messages resource bundle related > > to this module. > > Thus external message for e.g. security module could be obtained using next > > call: > > > > "org.apache.harmony.security.internal.MsgUtils.msg.getString(" security.1");" > > > > And at last, place to keep resources with external messages I suppose to be > > o.a.h.<module>.internal. > > > > If all these thoughts sounds reasonable, I'd like to implement framework > > mentioned above and send you a patch. > > > > -- > > Thanks, > > Ilya Okomin > > Intel Middleware Products Division > > > > > > --------------------------------------------------------------------- > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Alexey A. Petrenko Intel Middleware Products Division --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- -- Ilya Okomin Intel Middleware Products Division
