Uploaded image for project: 'Kuali Rice Development'
  1. Kuali Rice Development
  2. KULRICE-9117

Deprecate old formatters from core web, new formatter/property editor framework as part of krad data

    Details

    • 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

            Activity

            Hide
            ewestfal Eric Westfall added a comment -

            Consider leveraging org.springframework.format?

            Show
            ewestfal Eric Westfall added a comment - Consider leveraging org.springframework.format?
            Hide
            jkneal Jerry Neal (Inactive) added a comment -

            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

            Show
            jkneal Jerry Neal (Inactive) added a comment - 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
            Hide
            jkeller Jonathan Keller added a comment -

            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.

            Show
            jkeller Jonathan Keller added a comment - 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.
            Hide
            jkneal Jerry Neal (Inactive) added a comment -

            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

            Show
            jkneal Jerry Neal (Inactive) added a comment - 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
            Hide
            ewestfal Eric Westfall added a comment -

            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

            Show
            ewestfal Eric Westfall added a comment - 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
            Hide
            jkeller Jonathan Keller added a comment -

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

            Show
            jkeller Jonathan Keller added a comment - I'm going to stop work on this one for now. I've marked all the instances I found as deprecated.
            Hide
            ewestfal Eric Westfall added a comment -

            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.

            Show
            ewestfal Eric Westfall added a comment - 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.

              People

              • Assignee:
                jkeller Jonathan Keller
                Reporter:
                ewestfal Eric Westfall
              • Votes:
                0 Vote for this issue
                Watchers:
                4 Start watching this issue

                Dates

                • Created:
                  Updated:

                  Time Tracking

                  Estimated:
                  Original Estimate - 1 week, 2 days, 4 hours
                  1w 2d 4h
                  Remaining:
                  Remaining Estimate - 1 week, 2 days, 4 hours
                  1w 2d 4h
                  Logged:
                  Time Spent - Not Specified
                  Not Specified