commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel Florey" <daniel.flo...@web.de>
Subject AW: [i18n] proposals
Date Mon, 07 Feb 2005 11:10:08 GMT
Hi Woody,
you pass over your code to me directly using my apache email address.
See comments inline...

Cheers,
Daniel

> -----Urspr√ľngliche Nachricht-----
> Von: commons-dev-return-67427-daniel.florey=web.de@jakarta.apache.org
> [mailto:commons-dev-return-67427-daniel.florey=web.de@jakarta.apache.org]
> 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" <daniel.florey@web.de>
> 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: commons-dev-return-67318-daniel.florey=web.de@jakarta.apache.org
> > [mailto:commons-dev-return-67318-
> daniel.florey=web.de@jakarta.apache.org]
> > Im Auftrag von Anaximandro (Woody)
> > Gesendet: Samstag, 5. Februar 2005 06:03
> > An: Jakarta Commons Developers List; ozeigermann@apache.org
> > Betreff: Re: [i18n] status
> >
> > Thanx Oliver.
> >
> > I will wait for him,  :o
> >
> > Woody
> >
> > ----- Original Message -----
> > From: "Oliver Zeigermann" <oliver.zeigermann@gmail.com>
> > To: "Anaximandro (Woody)" <agodinhost@globo.com>
> > Cc: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
> > Sent: Friday, February 04, 2005 3:47 PM
> > Subject: Re: [i18n] status
> >
> >
> > > I am sure that your suggestions are valueable and you do not bore me
> > > at all. However, the proposals you made should be inspected by Daniel,
> > > as I have no deeper insight into neither contract nor i18n.
> > >
> > > Oliver
> > >
> > >
> > > On Fri, 4 Feb 2005 19:55:21 -0800, Anaximandro (Woody)
> > > <agodinhost@globo.com> wrote:
> > > > Oliver, I sent one proposal too (another class diagram, with a macro
> > vision
> > > > of my suggestions).
> > > >
> > > > The idea behind my suggestion is write one mediator (ConfigManager)
> to
> > > > retain one specific configuration (I can have many threads running
> > with
> > > > diferent configurations) and put one service locator in
> > MessageManager.
> > > >
> > > > Each message (LocalizedText, LocalizedMessage, etc) comunicates with
> > > > MessageManager through your configuration.
> > > >
> > > > I write a lot of code to test this ideas and to be more confident
> with
> > this
> > > > project, but now I stuck, this project is not mine and I need to
> take
> > easy
> > > > with ideas 8(
> > > >
> > > > You wanna see this class diagram? I'm boring you?
> > > >
> > > > Sorry
> > > >
> > > > Woody
> > > >
> > > > >
> > > > > I mainly work on xmlio, but am not aware of any proposed changes
> to
> > > > > the project. The class diagrams you sent have been put online by
> me.
> > > > >
> > > > > Oliver
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > 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
> 
> 
> ---------------------------------------------------------------------
> 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


---------------------------------------------------------------------
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