AW: [i18n] proposals

2005-02-07 Thread Daniel Florey
Hi Woody,
you pass over your code to me directly using my apache email address.
See comments inline...

Cheers,
Daniel

 -Ursprüngliche Nachricht-
 Von: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED]
 Im Auftrag von Anaximandro (Woody)
 Gesendet: Montag, 7. Februar 2005 06:12
 An: Jakarta Commons Developers List
 Betreff: Re: [i18n] proposals
 
 Hi Daniel,
 
 The ConfigManager in my idea is used for store specific configurations, as
 I
 see the MessageManager don't have this responsabilitie. If I store any
 configuration on MessageManager I will need specific instances of this guy
 for each thread with a diferent configuration.
 
 Well, in your code you don't let the user of this component to configure
 the
 behaviours of log, exceptions and default language. I do some code to do
 this in mine and,  becouse this, I need to store these configurations on a
 isolated place. Store these guys inside MessageManager is not a good
 idea.
 
 The MessageManager only store the message providers and delegate calls to
 these providers.
 
 The main objective behind this is to write less code in cases wich I need
 to
 specify Locales differents than default Locale. Instead of write:
 
 Locale userLocale = getUserLocale( userId );
 LocalizedText txt1 = new LocalizedText( consts.ID1, userLocale );//
 each
 message need to set the user locale
 LocalizedText txt2 = new LocalizedText( consts.ID2, userLocale );//
 LocalizedText txtN = new LocalizedText( consts.IDN, userLocale );  //

The locale is not specified in the constructor. It is specified when you
retrieve a particular entry:
LocalizedText txt1 = new LocalizedText( consts.ID1 );
String translatedText = txt1.getText(Locale.DE);
The default locale should only be used when no user locale can be detected.
It might be a good idea to remove the methods dealing with the default
locale in order to avoid confusion.

 
 I think in write:
 
 String  servletID= getServletUUID();
 
 ConfigManager config = new ConfigManager.getInstance( servletID );
 config.setLocale( getUserLocale( userId ) );
 // Only one place set the user locale
 
 LocalizedText txt1 = new LocalizedText( consts.ID1 );
 LocalizedText txt2 = new LocalizedText( consts.ID2 );
 LocalizedText txtN = new LocalizedText( consts.IDN );
 
 I agree with your idea, keep it simple here is the best thing to do, but
 how
 to setup aditional information without a mediator to store?
 The code in first example can be a problem, he multiply locale information
 (configuration) in many places where I have a message ...
 
 In my code I write:
 
 - In LocalizedText, LocalizedMessage, LocalizedError, LocalizedException I
 change the extensions. Instead of cascating extensios I do direct
 extensions
 (LocalizedText extends LocalizedBundle, LocalizedMessage extends
 LocalizedBundle, LocalizedError extends LocalizedBundle ...)

Why? Each extension adds some additional fields / methods.

 - new class: LocalizedRuntimeException (like your LocalizedException);

Good idea.

 
 * new class: ConfigManager (LocalizedBundle delegate to this class);
 - service locator;
 - code to config excetions and defaults ( useMessageIdAsDeafult(),
 useEntryIdAsDefault(), if both was false, then, we throw exceptions)
 - code to config log levels (setLevelLog2Info, setLevelLog2Warning and
 setLevelLog2Error);
 - code to setLocale (used by all messages in a given instance);
 - this class delegate calls to MessageManager;

Let me have a look at your code. Then it may become more clear ;-)
 
 
 * In MessageManager:
 - service locator;
 - methods to getProvider, removeProviders and reset/clear MessageManager;
 - move exception handling to ConfigManager (now it is configurable);
 - this class delegates class to each provider;
 
 * In XMLMessageProvider:
 - service locator;
 - move exception handling to ConfigManager;
 - more 2 xml formats (one file per message - as resource bundle does and a
 mix);
 
 * In ResourceBundleMessageProvider:
 - service locator;
 - move exception handling to ConfigManager;
 
 - In all classes I do some enhacements with final keyword;
 
 I do a lot of code and don't think is a good idea to put them here. How
 can
 I provide this to you? Did you have any email to I sent this? (sure, if
 you
 wish to see)
 
 Man, sorry by my english. Is more easy to me write code than write email
 ...
 If I write anything offensive, please, sorry and talk with me.
 
 Woody
 
 - Original Message -
 From: Daniel Florey [EMAIL PROTECTED]
 To: 'Jakarta Commons Developers List' commons-dev@jakarta.apache.org
 Sent: Saturday, February 05, 2005 5:58 AM
 Subject: AW: [i18n] status
 
 
 Hi Woody,
 Where did you post your proposals/patches? I'm very interested in
 improving
 the i18n/contract components.
 If you have any suggestions the best way is to describe the idea behind it
 so that it can be discussed in the mailing list. You can also post the
 related patches/files as attachment to a bugzilla entry (enhancement
 request).
 Please try

Re: [i18n] proposals

2005-02-06 Thread Anaximandro (Woody)
Hi Daniel,

The ConfigManager in my idea is used for store specific configurations, as I
see the MessageManager don't have this responsabilitie. If I store any
configuration on MessageManager I will need specific instances of this guy
for each thread with a diferent configuration.

Well, in your code you don't let the user of this component to configure the
behaviours of log, exceptions and default language. I do some code to do
this in mine and,  becouse this, I need to store these configurations on a
isolated place. Store these guys inside MessageManager is not a good idea.

The MessageManager only store the message providers and delegate calls to
these providers.

The main objective behind this is to write less code in cases wich I need to
specify Locales differents than default Locale. Instead of write:

Locale userLocale = getUserLocale( userId );
LocalizedText txt1 = new LocalizedText( consts.ID1, userLocale );// each
message need to set the user locale
LocalizedText txt2 = new LocalizedText( consts.ID2, userLocale );//
LocalizedText txtN = new LocalizedText( consts.IDN, userLocale );  //

I think in write:

String  servletID= getServletUUID();

ConfigManager config = new ConfigManager.getInstance( servletID );
config.setLocale( getUserLocale( userId ) );
// Only one place set the user locale

LocalizedText txt1 = new LocalizedText( consts.ID1 );
LocalizedText txt2 = new LocalizedText( consts.ID2 );
LocalizedText txtN = new LocalizedText( consts.IDN );

I agree with your idea, keep it simple here is the best thing to do, but how
to setup aditional information without a mediator to store?
The code in first example can be a problem, he multiply locale information
(configuration) in many places where I have a message ...

In my code I write:

- In LocalizedText, LocalizedMessage, LocalizedError, LocalizedException I
change the extensions. Instead of cascating extensios I do direct extensions
(LocalizedText extends LocalizedBundle, LocalizedMessage extends
LocalizedBundle, LocalizedError extends LocalizedBundle ...)
- new class: LocalizedRuntimeException (like your LocalizedException);

* new class: ConfigManager (LocalizedBundle delegate to this class);
- service locator;
- code to config excetions and defaults ( useMessageIdAsDeafult(),
useEntryIdAsDefault(), if both was false, then, we throw exceptions)
- code to config log levels (setLevelLog2Info, setLevelLog2Warning and
setLevelLog2Error);
- code to setLocale (used by all messages in a given instance);
- this class delegate calls to MessageManager;

* In MessageManager:
- service locator;
- methods to getProvider, removeProviders and reset/clear MessageManager;
- move exception handling to ConfigManager (now it is configurable);
- this class delegates class to each provider;

* In XMLMessageProvider:
- service locator;
- move exception handling to ConfigManager;
- more 2 xml formats (one file per message - as resource bundle does and a
mix);

* In ResourceBundleMessageProvider:
- service locator;
- move exception handling to ConfigManager;

- In all classes I do some enhacements with final keyword;

I do a lot of code and don't think is a good idea to put them here. How can
I provide this to you? Did you have any email to I sent this? (sure, if you
wish to see)

Man, sorry by my english. Is more easy to me write code than write email ...
If I write anything offensive, please, sorry and talk with me.

Woody

- Original Message - 
From: Daniel Florey [EMAIL PROTECTED]
To: 'Jakarta Commons Developers List' commons-dev@jakarta.apache.org
Sent: Saturday, February 05, 2005 5:58 AM
Subject: AW: [i18n] status


Hi Woody,
Where did you post your proposals/patches? I'm very interested in improving
the i18n/contract components.
If you have any suggestions the best way is to describe the idea behind it
so that it can be discussed in the mailing list. You can also post the
related patches/files as attachment to a bugzilla entry (enhancement
request).
Please try to describe each single idea / enhancement and include some code
snippets in the mail if it makes the idea clearer.
Regarding the proposal of a ConfigManager:
I'd like to keep the components as simple as possible. I've understood that
we need to have the ability to have more than one MessageManager per VM. So
my proposal would be just to add a getInstance(String messageManager) method
to the MessageManager and get rid of the static methods.
But perhaps I've missed the point. So it would be great if you could explain
in more detail what the ConfigManager is for.

Cheers,
Daniel

 -Ursprüngliche Nachricht-
 Von: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED]
 Im Auftrag von Anaximandro (Woody)
 Gesendet: Samstag, 5. Februar 2005 06:03
 An: Jakarta Commons Developers List; [EMAIL PROTECTED]
 Betreff: Re: [i18n] status

 Thanx Oliver.

 I will wait for him,  :o

 Woody

 - Original Message -
 From: Oliver Zeigermann [EMAIL PROTECTED]
 To: Anaximandro (Woody) [EMAIL