Phil Steitz wrote :
My recommendation is that we just modify the Mantissa class to
expose the key and parts (so add members for them) and add
getMessage(Locale). That is simple, not far from what we already have, and
sufficient to meet localization needs and support other sorts of processing
for
On 2/4/07, Luc Maisonobe <[EMAIL PROTECTED]> wrote:
Phil Steitz wrote :
>
> The problem with that is that generic handlers that display messages
would
> not work. I like the idea of carrying the data along, though and
exposing
> it, as well as providing translate (see
>
http://svn.apache.org/vie
I agree with Stephen that the commons libraries probably don't need
this type of support. They aren't doing anything that's "businessy"
enough (and they're not supposed to) to make it relevant to the user
(the user doesn't care that I'm using StringUtils to eat the white
space out of a String).
I'm sorry, but I find this extremely complicated and unreasonable. It
really, really, really isn't a direction I want commons to take.
Firstly, the use of a static will annoy the IoC (Spring) crowd, so that
aspect of the proposal seems flawed.
Secondly, this proposes adding a whole ream of ne
Phil Steitz wrote :
The problem with that is that generic handlers that display messages would
not work. I like the idea of carrying the data along, though and exposing
it, as well as providing translate (see
http://svn.apache.org/viewvc/jakarta/commons/proper/math/trunk/src/mantissa/src/org/spa
On 2/3/07, James Carman <[EMAIL PROTECTED]> wrote:
How would they subclass? The commons math code will be throwing these
exceptions themselves, no? They wouldn't be able to tell commons math
to throw a specific type of exception class that they wrote.
Yes, you're right.
I agree that the de
How would they subclass? The commons math code will be throwing these
exceptions themselves, no? They wouldn't be able to tell commons math
to throw a specific type of exception class that they wrote.
I agree that the default case (the JDK's getMessage() method) should
work so that nobody has t
Why not getMessage(ResourceBundle) so that the client apps can use
their own resource bundle if they wish? Or, provide a common
interface and "adaptors" that adapt different i18n mechanisms to your
paradigm. So, you'd have:
String getMessage( MessageSource src );
And, you'd have different "fla
On 2/3/07, James Carman <[EMAIL PROTECTED]> wrote:
How does a calling application override the message, if they wish?
They could subclass and override translate() or, assuming we take your
suggestion and carry the data along, they could access the data and do
whatever they want with it. I ag
How does a calling application override the message, if they wish?
On 2/3/07, Phil Steitz <[EMAIL PROTECTED]> wrote:
On 2/3/07, James Carman <[EMAIL PROTECTED]> wrote:
>
> Well, I wouldn't even provide a getMessage(Locale). I'd leave it up
> to the running application to resolve the message. F
On 2/3/07, James Carman <[EMAIL PROTECTED]> wrote:
Well, I wouldn't even provide a getMessage(Locale). I'd leave it up
to the running application to resolve the message. For instance, in
Tapestry, it doesn't use resource bundles to localize messages, at
least not directly in application code.
Well, I wouldn't even provide a getMessage(Locale). I'd leave it up
to the running application to resolve the message. For instance, in
Tapestry, it doesn't use resource bundles to localize messages, at
least not directly in application code. It uses a special Messages
object. So, I would prov
On 2/3/07, Phil Steitz <[EMAIL PROTECTED]> wrote:
On 1/30/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> Craig McClanahan wrote:
>
>
> > I'm late to the table on this thread, and only care about the Commons
> > libraries I care about :-)
>
> Thanks for your interest in this thread.
>
> > bu
So, nobody liked my idea of just providing the "data"?
On 1/30/07, James Carman <[EMAIL PROTECTED]> wrote:
How about if we give the "data" for the localized message instead of
localizing it ourselves? I've done this for a class I call
BusinessLogicException (used for when a user breaks a busine
On 1/30/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Craig McClanahan wrote:
> I'm late to the table on this thread, and only care about the Commons
> libraries I care about :-)
Thanks for your interest in this thread.
> but you should be aware that this attitude will
> disqualify the us
Craig McClanahan wrote:
> I'm late to the table on this thread, and only care about the Commons
> libraries I care about :-)
Thanks for your interest in this thread.
> but you should be aware that this attitude will
> disqualify the use of such libraries from use within code from organizations
How about if we give the "data" for the localized message instead of
localizing it ourselves? I've done this for a class I call
BusinessLogicException (used for when a user breaks a business rule
like "already a user with that name in the system" since you would
want to display that error message
On 1/28/07, Stephen Colebourne <[EMAIL PROTECTED]> wrote:
Phil Steitz wrote:
> I am interested in what others have to
> say about this as a general practice for commons. For [math]
specifically,
> I think it is important that we can fit seamlessly into localized
> applications, and we are refac
Concluding the thread.
Adding localization to exception is considered a wrong move by most people.
Adding an API to allow localization to be performed at application level
is a good way but implies probably both a large number of classes and a
large number of new methods (for example Mantissa
Jörg Schaible wrote:
My bottom line: If you build an application, you have
> to do localization (of exception and logging) at the application
> layer, because only there you can give the user a context, that is
> really useful. This implies catching exceptions from libraries and
> wrapping them
On 29/01/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Selon Jörg Schaible <[EMAIL PROTECTED]>:
[...]
> My bottom line: If you build an application, you have to do localization (of
> exception and logging) at the application layer, because only there you can
> give the user a context, that
Selon Jörg Schaible <[EMAIL PROTECTED]>:
> you cannot build a common
> library with meaningful exception messages (or log entries) that really makes
> sense for a user in the context of an application that builds on it.
This is often true, in this case the exception is caught by some middle laye
Hi Luc,
Luc Maisonobe wrote on Sunday, January 28, 2007 10:06 PM:
> Stephen Colebourne a écrit :
>
>> I disagree strongly with the whole concept of localized exception
>> messages. Localization for users yes, but developers no.
> [snip]
> > IMO, a localized application actually means localizati
Stephen Colebourne a écrit :
I disagree strongly with the whole concept of localized exception
messages. Localization for users yes, but developers no.
[snip]
> IMO, a localized application actually means localization for users, and
> implies nothing for developers.
I agree with both your rati
On 1/28/07, Stephen Colebourne <[EMAIL PROTECTED]> wrote:
Phil Steitz wrote:
> I am interested in what others have to
> say about this as a general practice for commons. For [math] specifically,
> I think it is important that we can fit seamlessly into localized
> applications, and we are refact
Phil Steitz wrote:
I am interested in what others have to
say about this as a general practice for commons. For [math] specifically,
I think it is important that we can fit seamlessly into localized
applications, and we are refactoring our exceptions hierarchy anyway, so I
say go for it.
I dis
On 1/28/07, Luc Maisonobe <[EMAIL PROTECTED]> wrote:
Hello,
As a non-native english speaker, I am quite eager to provide users with
libraries that can be embedded seemlessly into localized applications.
This implies that either the getMessage() and getLocalizedMessages() of
Exception instances
27 matches
Mail list logo
