Kuali Rice Development
  1. Kuali Rice Development
  2. KULRICE-8899

Introduce LocalCurrency and LocalDecimal data types

    Details

    • Type: Improvement Improvement
    • Status: Open Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: Backlog
    • Component/s: Development
    • Security Level: Public (Public: Anyone can view)
    • Labels:
    • Similar issues:
      KULRICE-6841UIF Framework - Introduce the concept of data element attributes
      KULRICE-4718Generalize data dictionary section structure and introduce Group concept
      KULRICE-7957Introduce layout options nested component class for item layout properties
      KULRICE-7275Replace -displaywith class logic (in refresh process) with data-labelfor
      KULRICE-6867On Term Spec maint doc, namespace, name, and data type should all be required.
      KULRICE-8819Add ByteArrayMultipartFileEditor to registered property editors to allow file types to bind to Byte[] data types
      KULRICE-9472Look into krad-data metadata storing/providing information about the "cache-ability" of data object types
      KULRICE-3738Review auto-loaded relationships to data which is part of the document type definition
      KULRICE-8320Improve data type validation error messages
      KULRICE-2225Create interfaces for the Role Type and Attributes
    • Rice Module:
      Rice Core
    • KAI Review Status:
      Not Required
    • KTI Review Status:
      Not Required
    • Include in Release Notes?:
      Yes

      Description

      I'm wondering if we should step back on the use of KualiDecimal. Keep it around, but as an option. It's relatively limiting, since it only allows two decimal places. Is there a reason that we should not just fall back (from a framework perspective) to basic types like BigDecimal? Otherwise, we are making an assumption that most users of the system want the same precision on everything.

      Then, what about introducing a replacement datatype called "LocalCurrency" It would use the Java-level default formatter as obtained from NumberFormat.getCurrencyInstance(). That would allow the UI to adapt to the location it's in and be explicitly identified as a monetary value.

      We might want a "LocalDecimal" as well, since the standard formatting of larger numbers can also vary by Locale.

      Just wanted to put this out there. I haven't really looked into KRAD to see how numbers are being handled. But, IMHO, KualiDecimal should be deprecated and retired in favor of both more flexible (LocalXxxxx) and more specific (Scale2Decimal, Scale4Decimal, etc...) types.

        Issue Links

          Activity

          Hide
          Jerry Neal (Inactive) added a comment -

          Also appear KualiInteger is formatting as a currency in KRAD

          Show
          Jerry Neal (Inactive) added a comment - Also appear KualiInteger is formatting as a currency in KRAD
          Hide
          Eric Westfall added a comment -

          By the way, there's a java.util.Currency class. Seems like we should be using that?

          Show
          Eric Westfall added a comment - By the way, there's a java.util.Currency class. Seems like we should be using that?

            People

            • Assignee:
              Unassigned
              Reporter:
              Jonathan Keller
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:

                Structure Helper Panel