[jira] Issue Comment Edited: (LANG-362) Add ExtendedMessageFormat to org.apache.commons.lang.text

["Niall Pemberton (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/LANG-362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12565260#action_12565260 ] 

niallp edited comment on LANG-362 at 2/3/08 8:31 PM:
--------------------------------------------------------------

You're right it hadn't hit my radar about toPattern() reconstructing the pattern from internal state and so my suggestion reflects only half the equation, i.e. pattern-to-Format and not Format-to-pattern.

The first thought I have about this is that one option would be to only support toPattern() for 1) existing MessageFormat compatiblity (i.e. the four "standard" built in formats) and 2) those configured through the pattern (i.e. not "non-standard" formats configured using the setFormat() methods). I believe this would be fairly straight forward to do and since EMF is providing a mechanism for using any format thru' the pattern then the use of setFormat() methods becomes unnecessary. 

Having said that even if full toPattern() support is an absolute must I still think the use of "meta formats" and the current implementation over-complicates things and my thinking goes along the following lines:

 - Using a meta "Format" implementation for the pattern<-->Format conversion is confusing in itself. I think this is where my Factory suggestion has merit since the idea of registering a "format factory" and then EMF looking-up a registered factory to create a Format is much more straight forward concept for users to grasp.

 - The current implementation does this kind of "look-up" (using NameKeyMetaFormat) but in an overcomplicated way - by creating an aggregated MultiFormat which tries to parse using delegated NameKeyMetaFormat which in turn delegates again if the format itself has arguments. Since the FormatElement part of message format's pattern is always {index, FormatType, args} then why have every meta-format repeatedly parse that info trying to match - my suggestion involved EMF extracting out the FormatType, looking up a registered factory for it and if found the factory then just parsing the arguments component. Surely this is simpler and less error prone than having to repeat the whole parsing of the FormatElement in every meta format?

 - If I didn't convice you with my earlier reasoning about whether full toPattern() support is really required then I think this can also be supported using the factory concept. It would reguire the "registry" to be more than a simple Map (i.e. be able to lookup a factory based on a Format, as well as name) and the FormatFactory would need additional method(s) to support re-creating the pattern - but I think that is doable as well.

Anyway I'm not wedded to my proposal (I generally try not to just throw out criticism since IMO what counts at the ASF is not talking, but doing) and have no problem it being dismissed - but I'm not convinced that what is there currently should be included in an official release. I think the concept is great, but supporting the code and users for this I think will be a headache that we regret down the line.

      was (Author: niallp):
    You're right it hadn't hit my radar about toPattern() reconstructing the pattern from internal state and so my suggestion reflects only half the equation, i.e. pattern-->Format and not Format-->pattern.

The first thought I have about this is that one option would be to only support toPattern() for 1) existing MessageFormat compatiblity (i.e. the four "standard" built in formats) and 2) those configured through the pattern (i.e. not "non-standard" formats configured using the setFormat() methods). I believe this would be fairly straight forward to do and since EMF is providing a mechanism for using any format thru' the pattern then the use of setFormat() methods becomes unnecessary. 

Having said that even if full toPattern() support is an absolute must I still think the use of "meta formats" and the current implementation over-complicates things and my thinking goes along the following lines:

 - Using a meta "Format" implementation for the pattern<-->Format conversion is confusing in itself. I think this is where my Factory suggestion has merit since the idea of registering a "format factory" and then EMF looking-up a registered factory to create a Format is much more straight forward concept for users to grasp.

 - The current implementation does this kind of "look-up" (using NameKeyMetaFormat) but in an overcomplicated way - by creating an aggregated MultiFormat which tries to parse using delegated NameKeyMetaFormat which in turn delegates again if the format itself has arguments. Since the FormatElement part of message format's pattern is always {index, FormatType, args} then why have every meta-format repeatedly parse that info trying to match - my suggestion involved EMF extracting out the FormatType, looking up a registered factory for it and if found the factory then just parsing the arguments component. Surely this is simpler and less error prone than having to repeat the whole parsing of the FormatElement in every meta format?

 - If I didn't convice you with my earlier reasoning about whether full toPattern() support is really required then I think this can also be supported using the factory concept. It would reguire the "registry" to be more than a simple Map (i.e. be able to lookup a factory based on a Format, as well as name) and the FormatFactory would need additional method(s) to support re-creating the pattern - but I think that is doable as well.

Anyway I'm not wedded to my proposal (I generally try not to just throw out criticism since IMO what counts at the ASF is not talking, but doing) and have no problem it being dismissed - but I'm not convinced that what is there currently should be included in an official release. I think the concept is great, but supporting the code and users for this I think will be a headache that we regret down the line.
  
> 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: DateFormatFactory.java, extendedMessageFormat.patch.txt, extendedMessageFormat.patch.txt, ExtendedMessageFormat2.java, FormatFactory.java
>
>
> Discussed on dev@ ( http://mail-archives.apache.org/mod_mbox/commons-dev/200710.mbox/%3c590921.30381.qm@web55103.mail.re4.yahoo.com%3e ); 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.