Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
Clear All
new posts

  • Blama
    replied
    Originally posted by Isomorphic View Post
    You can define a SimpleType with that validation built in and use it pervasively. This just means your DataSource definitions change from type="integer" to type="myInteger" (or whatever name), so it is no additional effort over trying to change the definition of the integer type itself, which would cripple the framework and could break internal functions.
    Great, thank you. I'll do that.

    Best regards
    Blama

    Leave a comment:


  • Isomorphic
    replied
    You can define a SimpleType with that validation built in and use it pervasively. This just means your DataSource definitions change from type="integer" to type="myInteger" (or whatever name), so it is no additional effort over trying to change the definition of the integer type itself, which would cripple the framework and could break internal functions.

    Leave a comment:


  • Blama
    replied
    Hi ppietras,
    Originally posted by ppietras View Post
    OK. We'll look into that.
    Thanks for response.
    please note that the attribute is not in the 5.0p docs (only 5.1d).

    Best regards
    Blama

    Leave a comment:


  • ppietras
    replied
    Originally posted by Isomorphic View Post
    These numbers are larger than JavaScript can natively represent with its Number type. See DataSourceField.stringInBrowser for framework options for dealing with this issue.
    OK. We'll look into that.
    Thanks for response.

    Leave a comment:


  • Blama
    replied
    FYI: The reason for the question is this sentence:
    Originally posted by docs
    Values submitted to the server will be converted to BigInteger if they exceed the range of Java's Long type. This happens during DSRequest validation, before any defined DMI methods are called.
    If interfering with DMI code, one must always do type checking for BigInteger, which means more unneeded LOC if you don't expect values out of the JavaScript range from a business perspective.

    Best regards
    Blama

    Leave a comment:


  • Blama
    replied
    Hi Isomorphic,

    after reading the linked docs for the new DataSourceField.stringInBrowser I'm wondering if it is somehow easily possible (perhaps with the SimpleType system?) to enable range validators for the range -2^53 to 2^53 for all type="integer" or type="float" fields.
    Of course I could add the validators by hand, but if SimpleType supports this, that would obviously be the better solution.

    I'm pretty sure that for my application (with no legacy data) the JavaScript range is enough for user data as well as PKs/FKs.

    Best regards
    Blama

    Leave a comment:


  • Isomorphic
    replied
    These numbers are larger than JavaScript can natively represent with its Number type. See DataSourceField.stringInBrowser for framework options for dealing with this issue.

    Leave a comment:


  • Problem with very large numeric values (bigint) - Smartgwt Power 4.1

    SmartClient Version: v9.1p_2015-05-06/PowerEdition Deployment (built 2015-05-06).
    GWT version 2.6.
    Tested on Firefox 24.7.0 and newer.

    I used nightly build from 6 may 2015 to test it.

    We use Power Edition.

    Problem occurred with databound ListGrid (SQLDataSource) with very large integer values (bigint, biginteger etc). They seem to be erroneously displayed and wrong values are returned by Listgrid itself.
    We have id '9223372036854775807' and it's wrongly displayed and than returned in client-side code as different value (we have custom fetches on this primary key value). The same happens for other large values. Since it's clients legacy database there is nothing we can do about thouse values.

    Problem occurred on ListGrid databound to postgresql 9.4 and mssql via SQLDataSource, but as a test case you can check showcase "Edit by cell":
    http://www.smartclient.com/smartgwt/...d_editing_cell

    If you put value '9223372036854775807' into "Population" it will be displayed as '9223372036854776000'.
    Last edited by ppietras; 14 May 2015, 04:27.
Working...
X