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]
