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. 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? 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. 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. Good luck with envinronment (to be honest I need to learn maven, I just used eclipse, always redoing the configuration when I need). 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]
