commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Niall Pemberton (JIRA)" <>
Subject [jira] Commented: (LANG-362) Add ExtendedMessageFormat to org.apache.commons.lang.text
Date Thu, 31 Jan 2008 04:35:39 GMT


Niall Pemberton commented on LANG-362:

OK I'll try and summarize the overall approach of your implementation:

 - ExtendedMessageFormat strips out all the "type" and "style" components from format elements
leaving only the 'placeholding' argument indexes and applies that pattern to the MessageFormat
it extends
 - ExtendedMessageFormat then parses the pattern again extracting the format element components
and uses the "meta format" to parse each format elements type and style and create a Format
for that element
 - These created formats are then set for the MessageFormat it extends.

This is obviously a simplification, but in order to achieve the second step (i.e. creating
the formats) it requires combing all the "meta format" implementations into a MultiFormat
to generate all the format types currently supported by MessageFormat, plus any custom format
types. So we have meta format implementations for date, time and number - plus a "factory"
for these standard types. On top of that we have NameKeyedMetaFormat for anyone wanting to
implement a custom format type and a couple of abstract support classes.
    - MetaFormatSupport
    - MultiFormat
    - ExtendedMessageFormat
    - NameKeyedMetaFormat
    - DefaultMetaFormatFactory
    - DateMetaFormat
    - DateMetaFormatSupport
    - NumberMetaFormat
    - TimeMetaFormat

Working out how this all hung together took me some time and I think it will be difficult
for users to grasp, difficult to support (I tried looking at the test cases to see how it
worked, but its not quick to see from them either - you have to scan thru' quite a bit of
code to find a real example of what you want to do).

IMO this can be a whole lot simpler - both in terms of code quantity and complexity and in
terms of concepts for users to grasp:

I believe we only need two types to support this functionality:
    - an ExtendedMessageFormat implementation
    - a (v. simple) FormatFactory interface

The FormatFactory interface has a single method as follows:
     Format getFormat(String name, String arguments, Locale locale);

It works something like this:

 - create a "registry" (i.e. java.util.Map) of additional format type factories (additional
to what MessageFormat already supports).
 - create an ExtendedMessageFormat instance with the "registry"
 - parse the pattern and for any format element types that have a factory registered, remove
the "type" and "style" components from the pattern and pass them to the factory to create
the format.
 - apply the modified pattern and set the formats for any created

I have hacked your ExtendedMessageFormat implementation to do this and will attach it here.
Its not properly tested and doesn't handle sub-formats ATM, but I believe it proves the concept
and will attach in a minute

> Add ExtendedMessageFormat to org.apache.commons.lang.text
> ---------------------------------------------------------
>                 Key: LANG-362
>                 URL:
>             Project: Commons Lang
>          Issue Type: New Feature
>            Reporter: Matt Benson
>            Assignee: Matt Benson
>            Priority: Minor
>             Fix For: 2.4
>         Attachments: extendedMessageFormat.patch.txt, extendedMessageFormat.patch.txt
> Discussed on dev@ (
); adding here for tracking purposes and in case anyone has any serious objections to my implementation.
 Patch forthcoming...

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message