Mailing-List: contact issues-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: issues@commons.apache.org
Message-ID: <775837201.1204129432905.JavaMail.jira@brutus>
Date: Wed, 27 Feb 2008 08:23:52 -0800 (PST)
From: "Matt Benson (JIRA)" <jira@apache.org>
To: issues@commons.apache.org
Subject: [jira] Commented: (LANG-362) Add ExtendedMessageFormat to
 org.apache.commons.lang.text
In-Reply-To: <23838880.1193088290565.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Matt Benson commented on LANG-362:
----------------------------------

{quote}
OK I have a couple of points
Custom sub-formats are not supported - so if I embed a "custom" format in a choice format it throws an IllegalArgumentException. Do we want to support that scenario or document clearly that it doesn't work?
(I did make this point in https://issues.apache.org/jira/browse/LANG-362?focusedCommentId=12564290#action_12564290)
{quote}

I had missed your having made that point.  I will look into this and see how heinous it is.

{quote}
Now the setFormats(), setFormat(), and setFormatByArgumentIndex() all throw UnsupportedOperationException I don't see the need for the logic to re-create the pattern - much simpler to just cache the pattern the EMF was created with and return that value in toPattern() - or am I missing something?
{quote}

Yes--jt.MF strips unnecessary whitespace and further may mangle e.g. date patterns if it can't differentiate between subformats (usu. because you've specified a pattern or style that collides with the system default); recreating the pattern allows the subclass to have output as close as possible to what would be created by the superclass (identical when no custom subformats are used).

{quote}
the test cases could (and IMO should) be simpler - currently there are four classes to test EMF (AbstractMessageFormatTest, ExtendedMessageFormatBaselineTest, MessageFormatExtensionTest. and MessageFormatTest) and I don't see why we don't just have one ExtendedMessageFormatTest). Tests are often a good way to look at how something works - so the simpler the better both for those maintaining it and users wanting to understand how to use it.
{quote}

I will concede that now that we are not reinventing the proverbial wheel the existing test cases are overkill.  :)

> 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, ExtendedMessageFormatTest.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.