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

    • 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?:
      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.

        Issue Links

          Activity

          Hide
          Eric Westfall added a comment -

          Consider leveraging org.springframework.format?

          Show
          Eric Westfall added a comment - Consider leveraging org.springframework.format?
          Hide
          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
          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
          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
          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
          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
          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
          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
          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
          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
          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
          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
          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:
              Jonathan Keller
              Reporter:
              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

                  Structure Helper Panel