commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Carman" <ja...@carmanconsulting.com>
Subject Re: [lang] notice of itch to commit
Date Fri, 05 Oct 2007 18:08:18 GMT
You mean this extension would allow some sort of "registry" which is
keyed by the second argument of the format expression?  So, I could do
something like...

ExtendedMessageFormat fmt = new ExtendedMessageFormat();
fmt.addFormatHandler("foo", new MyFooHandler() );
String str = fmt.format("Hello, {0,foo}!", "James Carman");

Now maybe you'd register the "handler" globally, but you get the idea.

On 10/5/07, Matt Benson <gudnabrsam@yahoo.com> wrote:
>
> --- Henri Yandell <flamefew@gmail.com> wrote:
>
> > Out of interest; related to a JIRA issue?
> >
>
> Actually no.  I guess I'll go ahead and lay my cards
> on the table in case anyone has any wisdom for me.  An
> obviously missing piece of java.text.MessageFormat is
> the ability to plug in other custom formatters.  I've
> only seen one OSS project (msg at java.net) that
> addresses this, and it has a dubious configuration
> mechanism (magic XML classpath resource) and an IMHO
> useless inheritance hierarchy i.e.
> java.lang.Object--the project claims its
> XMessageFormat is a "drop-in replacement" but
> apparently their idea of drop-in differs from mine.
> IMO such a solutiion would necessarily need to extend
> Format and very likely MessageFormat as well; a Format
> implicitly understood to operate upon Object[] is good
> enough from a javadoc POV but I have the feeling that
> much existing code would cope better with a
> MessageFormat subclass.  For these reasons I assert
> that I am not just indulging in NIH.  Lang already
> provides the CompositeFormat in o.a.c.lang.text; this
> constitutes IMO a precedent for custom Formats to live
> in Lang.  It is my intent to create
> o.a.c.lang.text.ExtendedMessageFormat (extends
> java.text.MessageFormat) with a pluggable means of
> resolving delegate formatters (optionally) specified
> with each "format element".  My intent is to provide a
> subclass whose default behavior is identical to its
> parent class but provides extensibility for plugging
> in custom formats.
>
> Comments?
>
> -Matt
>
> > On 10/4/07, Matt Benson <gudnabrsam@yahoo.com>
> > wrote:
> > > in org.apache.commons.lang.text
> > >
> > > -Matt
> > >
> > >
> > >
> > >
> >
> ____________________________________________________________________________________
> > > Pinpoint customers who are looking for what you
> > sell.
> > > http://searchmarketing.yahoo.com/
> > >
> > >
> >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail:
> > dev-unsubscribe@commons.apache.org
> > > For additional commands, e-mail:
> > dev-help@commons.apache.org
> > >
> > >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> > dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail:
> > dev-help@commons.apache.org
> >
> >
>
>
>
>
>
> ____________________________________________________________________________________
> Looking for a deal? Find great prices on flights and hotels with Yahoo! FareChase.
> http://farechase.yahoo.com/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

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


Mime
View raw message