6 Replies Latest reply: May 8, 2012 4:07 AM by Dimitar Dimitrov RSS

    Numeric formats

    Filip Huysmans
      Hello everyone,

      JDev 11.1.1.5.0; OS Windows7
      We are using ADF BC, Model & Faces RC

      We want to show a numeric field with the format "####,#####", where the "," is the decimal seperator.
      How can we achieve this?

      We've already tried several things like setting the format in the EO attribute, changing the convertNumber tag directly. All without success.
      The main questions are :
           * What is the best attribute type to use for this kind of situations? BigDecimal, Number, Long, ...?
           * What is the correct format to use?
           * What should we do to make the "," the decimal seperator and to not have any group seperator?

      Thank you very much in advance.

      Filip Huysmans.
        • 2. Re: Numeric formats
          Filip Huysmans
          Hi Sudipto Desmukh,

          Thanks for the link.
          We have now created this custom converter. The only thing it does is replacing the "," by "." and the "." by ",".
          But now we have a problem with the precision/scale.
          Once we enter a value with a decimal value, we receive the following error : Attribute set with value ... for ... has invalid precision/scale.

          Our field in the db is Number(9,5). The type in the EO is BigDecimal. The format type in EO is Number.
          If we leave the format property of the attribute in the EO, empty => then all information after the decimal point is removed
          Whenever we set the format property, we always get this error message. We know it is generated by the validation that has been created automatically by the wizard based on the information in the db.

          We have tried the following formats : ##.## and 00.00 and ####.#####
          all resulted into the error.

          Any ideas?

          Thank you in advance.

          Filip.
          • 3. Re: Numeric formats
            Filip Huysmans
            Hi everyone,

            I ended up with creating a custom validator and converter.
            It now seems to be working, like expected.

            Still a bit strange, that for this simple requirement, one must create a custom validator and converter.
            I'm still convinced that there should be a much easier way to achieve this.

            Still hoping on some interesting pointers ...

            Thank you in all in advance.

            Filip
            • 4. Re: Numeric formats
              Jan Vervecken
              hi Filip
              Filip Huysmans wrote:
              ... Still a bit strange, that for this simple requirement, one must create a custom validator and converter.
              I'm still convinced that there should be a much easier way to achieve this.

              Still hoping on some interesting pointers ...
              Maybe you could consider creating an ADFEMG JIRA issue
              via http://java.net/projects/adfemg at http://java.net/jira/browse/ADFEMG
              where a description of reproducible behaviour could result in an Oracle bug and/or enhancement request (if not a solution).

              success
              Jan Vervecken
              • 5. Re: Numeric formats
                Filip Huysmans
                Hi Jan,

                good idea. I'll do that.

                Thanks.

                Filip
                • 6. Re: Numeric formats
                  Dimitar Dimitrov
                  Hi Filip,

                  It is not necessary to create a custom converter for such a simple case.

                  The decimal point character (either "." or ",") depends on the locale. For example, if the locale is the US locale, then the decimal point character is "." and the grouping separator (e.g. thousands separator) is "," , but when the locale is the Bulgarian locale, the decimal point character is "," and the grouping separator is " " (a non-breakable space). You do not have to create a custom converter, but you have to ensure that the correct locale is used. (The locale depends on the settings of the browser, faces-config.xml, <f:view>).

                  Also there are some tricky things related to the ADF bindings and converters:

                  = If you specify a pattern in <af:convertNumber>, then the converter will be server-side only (have a look at the documentation of <af:convertNumber>) and it will be applied only when the value is submitted to the server. If you want the conversion to be applied immediately at client side after the user exits the field (even if no autoSubmit has been configured), then you should not use the "pattern" attribute but a combination of other attributes of <af:convertNumber> (for example, "minFractionDigits", "maxFractionDigits", "minIntegerDigits", "maxIntegerDigits", "groupingUsed").

                  = If you have specified a format mask in the EO/VO attribute definition, then the attribute binding applies conversion and the binding's "inputValue" property returns a formatted string instead of a numeric object, so the eventual <af:convertNumber> tag is more or less useless. The good news is that you can skip the automatic conversion applied by the attribute binding if you bind the <af:inputText> component to the "attributeValue" property of the binding instead of the "inputValue" property (for example, use <tt>value="#{bindings.<myAttr>.attributeValue}"</tt> instead of <tt>value="#{bindings.<myAttr>.inputValue}"</tt>). Then the eventual <af:convertNumber> converter will control the whole conversion.

                  ---

                  At the end I would like to say a few words about the numeric datatypes. The built-in Precision&Scale validator checks the fraction digit count by using the toString() method of the corresponding numeric object. I did have some problems with BigDecimal in past, which were related to fraction digits far after the decimal point and which resulted in precision&scale validation errors. Float and Double types are not suitable either, because their toString() methods format the value in an exponential format when the fraction part contains more than 3 digits (e.g. 0.1234512E+02) which causes presicion&scale validation errors (because the number of the characters after the decimal point is large). My advise is to use oracle.jbo.domain.Number, which does not cause such problems.

                  Dimitar