Details
-
Type:
Improvement
-
Status: Open
-
Priority:
Critical
-
Resolution: Unresolved
-
Affects Version/s: None
-
Fix Version/s: 2.6
-
Component/s: Analysis, Development, JPA, KNS Equivalency, Roadmap
-
Security Level: Public (Public: Anyone can view)
-
Labels:
-
KRAD Feature Area:Data Dictionary
-
KAI Review Status:Not Required
-
KTI Review Status:Not Required
-
Include in Release Notes?:Yes
Description
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.
Attachments
Issue Links
- relates to
-
KULRICE-9212 Rework KRAD Property Editors/Formatters
-
- Open
-
| 1. | Convert all existing Formatter instances to PropertyEditor | KULRICE-9473 |
|
Open | Unassigned |
Activity
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.
Jerry
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.
Jonathan,
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.
thanks,
Jerry
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 
I'm going to stop work on this one for now. I've marked all the instances I found as deprecated.
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.
Consider leveraging org.springframework.format?