commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dennis Lundberg <dennis.lundb...@mdh.se>
Subject Re: [i18n] Entry qualifier
Date Mon, 18 Apr 2005 21:20:12 GMT
Mattias J wrote:
> Will Ant be abandoned in favor of Maven or should I update the Ant 
> script to include the unit tests? (I have no experience with Maven)
> What indentation do you use for XML? I find both tabs and 2 spaces, even 
> in the same file. (There is also a tab on line 80 in LocalizedBundle.java)
> 
> I have set up the environment and started working on some unit tests. I 
> think one of them caught a bug in MessageHandler. My guess is
>         try {
>             String text = getText(id, entry, arguments, locale);
>             return MessageFormat.format(text, arguments);
>         } catch (MessageNotFoundException e) {
>             return defaultText;
>         }
> 
> should read
>         try {
>             return getText(id, entry, arguments, locale);
>         } catch (MessageNotFoundException e) {
>             return MessageFormat.format(defaultText, arguments);
>         }
> 
> right?
> 
> (B.t.w. is there a tutorial on creating SVN patches somewhere?)

The superb free online book "Version Control with Subversion" has a 
section about it at:
http://svnbook.red-bean.com/en/1.0/ch03s05.html#svn-ch-3-sect-4.3.2

--
Dennis Lundberg


>   Mattias Jiderhamn
> 
> At 2005-04-18 13:24, Daniel Florey wrote:
> 
>> "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org> 
>> schrieb am 18.04.05 11:29:38:
>> >
>> > At 2005-04-18 11:11, Daniel Florey wrote:
>> > > > My though was to re-use the basename or id used when "installing"
>> > > > ResourceBundle or XML providers. For example, after issuing
>> > > >    ResourceBundleMessageProvider.install("errorMessages");
>> > > > I would like to be able to qualify the newly installed messages 
>> with
>> > > >    MessageBundle msg = new MessageBundle("errorMessages",
>> > > "unexpectedError");
>> > > > but also keep the existing alternative with
>> > > >    MessageBundle msg = new MessageBundle("unexpectedError"); //
>> > > > "unexpectedError" from any source
>> > >
>> > >Do you want this to be able to install different resources with the 
>> same
>> > >message key or is it mainly because of implementation details 
>> (performance)?
>> >
>> > Primarily multiple entries with same key, secondarily performance.
>> >
>> > > > This may seem like a minor change at a first glance, but to also 
>> improve
>> > > > performance my thought was to to change the MessageManager class 
>> from
>> > > > holding a list of provider instances - which in turn can contain 
>> multiple
>> > > > resources (and thus assumes one instance per provider class) - to
>> > > holding a
>> > > > Map from basename/id/namespace/qualifier to provider instance, 
>> where each
>> > > > instance only contains a single resource (i.e. 
>> XML-file/ResourceBundle).
>> > > > Though I planned on backwards compatibilty, by looping over the 
>> Map values
>> > > > - instead of the List entries - in the current 
>> MessageManager.getText()
>> > > method.
>> > > > (Did I make myself clear?)
>> > >
>> > >I try my best to get your point...
>> > >At the moment there is only one MessageProvider holding many 
>> resources.
>> > >You want to change this to many MessageProviders holding one 
>> resource each
>> > >in order to improve performance?
>> >
>> > Yes. Instead of having to loop through the providers - catching 
>> exceptions
>> > from those who do not contain the entry, which is quite costly 
>> performance
>> > wise - and get the first match, I want to be able to point out the 
>> source
>> > which I expect to hold the entry. But then again, todays behaviour 
>> should
>> > be kept as the default behaviour when not using a basename/namespace
>> > qualification.
>> >
>> > >I currently don't have access to the sources as I'm on a project in 
>> Jordan
>> >
>> > (You can browse them online,
>> > http://jakarta.apache.org/commons/sandbox/i18n/xref/index.html is quite
>> > easy to navigate)
>> >
>> > >but as soon as I'm back home I'll try to have a closer look at this.
>> >
>> > Should I try to create a patch suggestion which you could look at then?
>>
>> Yes, this would be great!
>> It would be very (very) appreciated, if you could provide some 
>> testcases... I started to write some a while ago, but never managed to 
>> complete them. If we would have a complete testsuite we could refactor 
>> without the fear to break something ;-)
>> If we get the testsuite done and improve the documentation, we 
>> hopefully can move the component to commons proper soon...
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 

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


Mime
View raw message