Hi Woody, Thanks for your help! See comments inline... Daniel
> -----Ursprüngliche Nachricht----- > Von: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > Im Auftrag von Anaximandro (Woody) > Gesendet: Mittwoch, 16. Februar 2005 11:17 > An: Jakarta Commons Developers List > Betreff: Re: [i18n] man available > > Hello Daniel, > > Yup, the ConfigManager not prove to be very usefull. This class is > increasing the coupling level to give me a few features set (the con > figuration features itself) and gave me much more code to delegate ... > > But you don't think necessary some code to configure the behaviours of > this component? For instance: in your version when the component not > find one message id they throw one unchecked exception. The component > dont't force me to write one try catch block for each LocalizedEntry but > force me to write all messages ids in their respective resource to avoid > one exception. Avoid try catch blocks is cool, very cool, but this only > make my code more clean, however the cost to do this is high: I must write > the messages id (at least) to don't break the application, but if I forget > one id the application will break in same mode. I'll add some examples to the website that show how to deal with missing messages, ok? > > Using some code to configure this helps in this situation. I can talk to > component: hey pal, use the message id or entry id as default when you not > find someone. Don't throw an exception, instead, write this in log. I > will write these messages later ok? I try to avoid including logging into the i18n component as there are so many different loggers around. I just removed the commons-xmlio dependencies by using sax-parsing instead, so my goal is to achieve a component with no dependencies. If we need logging, I'd vote for standard jdk 1.4-logging. What do you think? > > Hence I think is better to leave this decision to the user component. I > know you wanna a small and easy to use component, I want the same think, > but ... I think is more easy to use a componente wich can be configured > than one wich we can't do this. > > Sorry if I'm talking to much, I really wanna help but my english make this > more hard than really is. > > Only one MessageManager? no getInstance? As I see the problem exists > when many threads (with different Locales) try to get a message. I don't > see any problem with diferent applications (sure, the unique ID is requi > red). If you use only one MessageManager you will need to always provide > the desired Locale (in constructor or in getXXX method) because there is > no more a place to store a default Locale info since the older place > (setLocale/getLocale) will be shared by this threads. More than this, > doing this will bestrew Locale info in resulting client code making this > more hard to update. Well, this is just my opinion. It is necessary to provide the desired locale in each getXXX method of the LocalizedBundle-subclasses. I just removed the ones using the default locale as this causes additional confusion. If you really want to specify a thread-specific locale (??) then you need to store it in ThreadLocal. I'll add a method to set the default locale in the MessageManager if it should be something different than the VM default locale. > > I try to solve this writing the getInstance (as you suggest in email) > but with this I create another problem: how to link a message with their > respective manager? Passing this guy as parameter? nope, this is ugly. So > writing some method to returns the current manager? Yes, make sense, then: > getCurrentInstance, but, again, I created another problem: I need to write > monitor code to lock unlock the instance to avoid data corruption (between > threads). I think this is the last thing I need to close my version. I > will > do this (is a little hard to me because I never do this before). > > I'm right im my point? I miss something? > > Did you find some good idea in my code? If you do I can revise and > generate > the apropriate patch to you. Yes, thanks. I'll add some LocalizedRuntimeException, LocalizedError etc. and rename the LocalizedError to something more speaking. > > Good luck with envinronment (to be honest I need to learn maven, I just > used eclipse, always redoing the configuration when I need). Maven is a nice tool, but very bad documented indeed. So it's hard to figure out how to achieved the desired stuff... > > Woody > > >Hi Woody, > >I'm currently trying to improve the maven environment, so that releases > and > >tests can easily be done. > >My goal is to complete the component in the actual state in order to > build > a > >usable release as soon as possible. > >I've already had a look at your proposed changes. I'd like to include > some > >changes into the current version (LocalizedRuntimeException), but I'm not > >sure with the ConfigManager. This one introduces a lot of complexity. > >In order to keep the i18n-component very simple my suggestions would be > to > >keep only one MessageManager with static methods and advice the user to > use > >unique message keys (comparable to java package names). This should avoid > >trouble when using multiple applications. Agreed? > >Next steps are to remove misleading methods (as we discussed earlier) and > to > >complete the javadocs and provide some more tutorials. This is the part > >where help would be very much appreciated ;-) > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
