Issue Details (XML | Word | Printable)

Key: DISPL-374
Type: Bug Bug
Status: Open Open
Priority: Major Major
Reporter: Marco Papini
Votes: 2
Watchers: 3
Operations

If you were logged in you would be able to see more operations.
DisplayTag

MessageFormatColumnDecarator fails on a date property when escapeXml=true

Created: 12/Jul/06 05:02 AM   Updated: 12/Jul/06 05:20 AM
Component/s: Decorators
Affects Version/s: 1.1
Fix Version/s: None

Time Tracking:
Not Specified

File Attachments: 1. Java Source File ColumnTag.java (30 kB)


Application server: Apache Tomcat 5.5.16


 Description  « Hide
I've tried to use the 'format' attribute of <display:column> tag to decorate a date property, but I get the following error in the log and the column remains unformatted:

ERROR MessageFormatColumnDecorator.decorate(66) | Caught an illegal argument exception while trying to format an object with pattern {0,date,dd/MM/yyyy}, returning the unformatted value. Object class is {0,date,dd/MM/yyyy}

The problematic column:

    <display:column property="inizioValidita" sortable="true" escapeXml="true"
         titleKey="fields.inizioValidita" format="{0,date,dd/MM/yyyy}"/>

I've tracked down the problem to the class MessageFormatColumnDecorator, line 62: the columnValue was a String instead of a Date. I think this i caused by another decorator, EscapeXmlColumnDecorator, that converts to String any Object it decorates. So I've tried to use escapeXml="false" in the above column tag and it worked.

I think that MessageFormatColumnDecorator should be the first decorator applied and the EscapeXmlColumnDecorator the last one to fulfill the Principle of Least Surprise.

BTW, I've also noticed that 4 tests fails when compiling the sources of 1.1 distribution

 All   Comments   Work Log   Change History      Sort Order: Ascending order - Click to sort in descending order
Marco Papini added a comment - 12/Jul/06 05:20 AM
Here's an update ColumnTag.java, where I move the MessageFormatColumnDecorator as the first decorator in the decorator List. This solves the problem I reported with escapeXml="true".
I didn't test it other than this.