commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Anaximandro (Woody)" <agodinh...@globo.com>
Subject Re: [i18n] man available
Date Wed, 16 Feb 2005 10:16:32 GMT
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message