[
https://issues.apache.org/jira/browse/LANG-362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12564290#action_12564290
]
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: https://issues.apache.org/jira/browse/LANG-362
> 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@ (
> http://mail-archives.apache.org/mod_mbox/commons-dev/200710.mbox/[EMAIL
> PROTECTED] ); 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.
