[KULRICE-9117] Deprecate old formatters from core web, new formatter/property editor framework as part of krad data Created: 08/Mar/13  Updated: 16/Jan/15

Status: Open
Project: Kuali Rice Development
Component/s: Analysis, Development, JPA, KNS Equivalency, Roadmap
Affects Version/s: None
Fix Version/s: 2.6
Security Level: Public (Public: Anyone can view)

Type: Improvement Priority: Critical
Reporter: Eric Westfall Assignee: Jonathan Keller
Resolution: Unresolved Votes: 0
Labels: Old
Σ Remaining Estimate: 1 week, 2 days, 4 hours Remaining Estimate: 1 week, 2 days, 4 hours
Σ Time Spent: Not Specified Time Spent: Not Specified
Σ Original Estimate: 1 week, 2 days, 4 hours Original Estimate: 1 week, 2 days, 4 hours

Issue Links:
relates to KULRICE-9212 Rework KRAD Property Editors/Formatters Open
KULRICE-9473 Convert all existing Formatter instan... Sub Task Open  
KRAD Feature Area:
Data Dictionary
KAI Review Status: Not Required
KTI Review Status: Not Required
Include in Release Notes?:


I'm not sure exactly what this will mean, but our old-school formatter framework is part of the core.web package at the moment and I think we could do better. I wonder if there are other "formatter" frameworks out there that we should look at (does spring give us something?)

Formatters in core web should be deprecated, new formatters in org.kuali.rice.krad.data.format package. And of course we need to have support in new metadata for this.

Comment by Eric Westfall [ 08/Mar/13 ]

Consider leveraging org.springframework.format?

Comment by Jerry Neal (Inactive) [ 23/Mar/13 ]

Spring does have formatters but also supports property editors. We are using property editors currently in KRAD because there was some restriction of how formatters could be associated with attributes for binding. I would like to take another look at that. I think it would be good though if we are consistent between the UI and data layers in what we use.


Comment by Jonathan Keller [ 25/Mar/13 ]

Jerry - would property editors be used for read only displays as well? I worry that we may have two use cases here:

In the case of a numeric field, we would want the read only value to be displayed as 1,234.56. But, in an editable field, it would just be 1234.56.

Comment by Jerry Neal (Inactive) [ 25/Mar/13 ]


Currently it does, but I agree I don't think that is what we want. Seems like a PropertyEditor should be used for datatype conversion (String to KualiDecimal), and a formatter for read only display. But Spring uses the PropertyEditor for both. In the KNS, did the formatter only apply when a field was read-only? I can't recall.

I am going to spawn off a new Jira to revisit this in KRAD and link to this.


Comment by Eric Westfall [ 26/Mar/13 ]

Thanks Jerry, sounds like there is some new stuff to investigate here. I think the end game is that it would be good to move forward with a framework provided for us by one of the libraries we are using as opposed to continuing with an "invented here" implementation. I like to find way to reduce our code footprint whenever it's possible to do so

Comment by Jonathan Keller [ 15/Apr/13 ]

I'm going to stop work on this one for now. I've marked all the instances I found as deprecated.

Comment by Eric Westfall [ 15/May/13 ]

i really wasn't sure what to put on this one as an estimate. It looks like there is some related work planned to be done for 2.3 (see the linked issue) so I'm not sure how much additional work will need to flow our way as a result.

Generated at Wed Aug 12 21:19:36 CDT 2020 using JIRA 7.0.11#70121-sha1:19d24976997c1d95f06f3e327e087be0b71f28d4.