Re: [Phoenix] Exceptions, Events and i18n

[Peter Donald <do...@apache.org>]

Hi,

I haven't been successful in doing this and there is a few different models
that I am unsure which way to go. 

Lets assume there are N different types of status/error messages in the
kernel/applications. Each different message may have 0, 1 or more
parameters. Some of these messages belong to a "family" where each member
of family takes same parameters. (ie they may all take name of block or
numeric). 

There is a few different ways of doing this

(1) Each message has a different method. ie

listener.componentAdded( "myBlock" );
listener.errorLoadingComponent( "myBlock", myException );
listener.componentUnloaded( "myBlock" );
 
(2) Generic code + generic parameter list method
listener.status( Status.COMPONENT_ADDED, new Object[] { "myBlock" } );
listener.error( Status.ERROR_LOADING, 
                new Object[] { "myBlock", myException } );
listener.status( Status.COMPONENT_UNLOADED, new Object[] { "myBlock" } );

(3) Semi-stateful listeners

listener.componentAdded( "myBlock" );

// Note we know that the next message pertains to "myBlock" because
// it was last named in call to componentAdded()
listener.errorLoadingComponent( myException );

listener.componentUnloaded( "myBlock" );

(4) Force errors in same "family" into same method

listener.lifecycleStatus( Status.COMPONENT_ADDED, "myBlock" );
listener.lifecycleError( Status.ERROR_LOADING, "myBlock", myException );
listener.lifecycleStatus( Status.COMPONENT_UNLOADED, "myBlock" );

Or something else ?

Which method is the most correct? Probably (1) - however it can get
excessive as there will likely be close to 30 messages. Anyone else have
ideas/opinions etc?

Cheers,

Pete

*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof."                   |
|              - John Kenneth Galbraith               |
*-----------------------------------------------------*


---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org

Re: [Phoenix] Exceptions, Events and i18n

[Rob Walker <ro...@softsell.com>]

Woops, I'm unintentionally "noisy" on the email list for a newbie. 
Internationalisation was the one piece I left off my questions email 
for fear of throwing out too much garbage. It's a key area for us tho. 
so here goes.

> Lets assume there are N different types of status/error 
messages in the
> kernel/applications. Each different message may have 0, 1 or 
more
> parameters. Some of these messages belong to a "family" where 
each member
> of family takes same parameters. (ie they may all take name of 
block or
> numeric). 

* Let me check my assumptions - actually Internatilising the 
messages is well covered using the standard JDK combination of:

- MessageFormat & ChoiceFormat classes
- Locale specific .properties files and ResourceBundles

So what I think you're looking for is some higher abstraction i.e. if 
we have 100 different error/status messages, all with different 
numbers and kinds of placeholder replacement arguments, how 
best to group and collect them?

> There is a few different ways of doing this
> 
> (1) Each message has a different method. ie
> 
> listener.componentAdded( "myBlock" );
> listener.errorLoadingComponent( "myBlock", myException );
> listener.componentUnloaded( "myBlock" );

Taking an example of 3 messages, all of which take a single 
argument that is a String containing a filename e.g. 

	File {0} is full
	File {0} cannot be found
	File {0} is locked 

Whether to group them as "FileMessages" or even 
"FileMessagesSingleArg" (both with a defined/common array of 
parameters). Or whether to say each is separate e.g.

	Message.FileFull (... )
	Message.FileNotFound (...)
	Message.FileLocked (... )

Pain that it might be, I'd say the latter. Any change to one of the 
message's construction or argument lists will not pollute the others 
unintentionally. 

> (2) Generic code + generic parameter list method
> listener.status( Status.COMPONENT_ADDED, new Object[] { "myBlock" } );
> listener.error( Status.ERROR_LOADING, 
>                 new Object[] { "myBlock", myException } );
> listener.status( Status.COMPONENT_UNLOADED, new Object[] { "myBlock" } );

I think the standard MessageFormat stuff will take care of this 
approach for you ... albeit, the arguments passed in code must 
match the text patterns and there's only programmer integrity to 
police this.

> 
> (3) Semi-stateful listeners
> 
> listener.componentAdded( "myBlock" );
> 
> // Note we know that the next message pertains to "myBlock" because
> // it was last named in call to componentAdded()
> listener.errorLoadingComponent( myException );
> 
> listener.componentUnloaded( "myBlock" );
> 
> (4) Force errors in same "family" into same method
> 
> listener.lifecycleStatus( Status.COMPONENT_ADDED, "myBlock" );
> listener.lifecycleError( Status.ERROR_LOADING, "myBlock", myException );
> listener.lifecycleStatus( Status.COMPONENT_UNLOADED, "myBlock" );
> 
> Or something else ?
> 
> Which method is the most correct? Probably (1) - however it can get
> excessive as there will likely be close to 30 messages. Anyone else have
> ideas/opinions etc?

Trouble comes (and this is a big headache for us) when you have 
1000 messages and each needs a locale specific text, and a 
separate method (or worse) to represent it.

I suspect we'll going to tackle this by a combination of (1) and (4) e.g. a
way for individual messages to delegate their argument handling to 
a common method e.g. StandardFileMessageParams

FYI (at the risk of teaching you to suck eggs) there's an 
internatilization toolkit at:

	http://java.sun.com/products/jilkit

-- Rob --


SoftSell Business Systems, Ltd.
' testing solutions for a changing world '
 
+44 (20) 7488 3470
www.softsell.com
robw@softsell.com

---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org