[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  
Similar issues:
KULRICE-5600Uif Framework: Change Formatter property on AttributeField to PropertyEditor
KULRICE-9140Deprecate PersistenceStructureService and related old metadata services
KULRICE-11491Remove duplicated test resources from KRAD web framework
KULRICE-4258Inconsistent use of Formatters in maintenance framework
KULRICE-10120Attribute Definition: Conversion Guide
KULRICE-9212Rework KRAD Property Editors/Formatters
KULRICE-9473Convert all existing Formatter instances to PropertyEditor
KULRICE-9889Move deprecated data code and services to the rice-kns module
KULRICE-5041Migrate xml import/export framework to the Rice core
KULRICE-9556Move all deprecated data/persistence code to rice-kns module
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 Sat Jan 18 22:03:11 CST 2020 using JIRA 6.1.5#6160-sha1:a61a0fc278117a0da0ec9b89167b8f29b6afdab2.