Alexey Petrenko wrote:
> Geir,
>
> I've reread your email in the morning :)
>
> Internationalization classes auto-generation is really good idea. We
> can apply it for method described here and for "new Eclipse" method.
I'll settle for it being "an idea". Not sure if it's a good one. Tim
has been working in this area, and I'm interested to hear what he thinks.
>
> In the first case "generator" will insert correct resource bundle and
> package name. In the second one we can generate the supporting class
> from the resource bundle file.
>
> There will be 2 big differences between this two methods:
> 1. Initialization time: much faster for the "first" method
> 2. Run time access time: much faster for the "second" method
>
> So if we will have situation with the big resource file and small
> number of accesses to it then the "first" method will be faster. In
> the case with large number of accesses the "second" method will be
> more preferable.
Can you quantify what "much faster" is for both cases?
>
> Probably we should think about using both methods depends on the purpose.
>
> For example. For UI application we have a huge number of messages
> which are widely used during normal run (menu items, user messages
> etc) and in this case the "second" method seems better.
> Otherwise for the code without user interaction the messages from the
> bundle will be mostly used as error messages for the throwing
> exceptions. We hope that exceptions will not happen very often. And we
> know that throwing an exception is rather long operation. So in this
> case the "first" method seems better.
>
> Hmm... It looks like I've found an argument for using traditional
> method in class library :)
:)
>
> SY, Alexey
>
> 2006/7/11, Geir Magnusson Jr <[EMAIL PROTECTED]>:
>>
>>
>> Tim Ellison wrote:
>> > Ilya Okomin wrote:
>> >> I'd like to be a volunteer for that.
>> >
>> > I just started working in this area (for SQL), maybe that is what
>> > prompted you...<g>
>> >
>> >> 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");"
>>
>> >
>> > I see your point, and considered doing it that way too. I'm not overly
>> > concerned about the duplication, they are trivial helper methods
>> anyway,
>> > and we all know that singletons are evil ;-)
>>
>> I don't understand this, given you have one...
>>
>> >
>> >> And at last, place to keep resources with external messages I
>> suppose to be
>> >> o.a.h.<module>.internal.
>> >
>> > I went for o.a.h.<module>.internal.nls just to keep them tidy.
>> >
>> >> If all these thoughts sounds reasonable, I'd like to implement
>> framework
>> >> mentioned above and send you a patch.
>> >
>> > The real work is going through and externalizing all the messages, and
>> > if I were to be really ambitious to add messages to all the exceptions
>> > that we throw that don't have anything right now.
>> >
>> > Patches are always welcome. We can work on that that as we finalize on
>> > the framework.
>>
>> Have you had any thoughts about a 'common' code set, that is copied and
>> modified at build time, setting the right package name and bundle name
>> by convention? That would remove the need to duplicate the code.
>>
>> geir
>>
>>
>> ---------------------------------------------------------------------
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
