Invalid input for numbers

  • 1
  • Question
  • Updated 4 years ago
  • Answered
I have a Salesforce number field with no decimal places. I am adding this field to a skuid form and try to save it.
If the user enters "2 Hello 3" ... skuid translates this to "23" stripping out any text. How can I have proper validation on my input to have validation similar to Salesforce which will display "Invalid Number".
Photo of Amr


  • 256 Points 250 badge 2x thumb

Posted 4 years ago

  • 1
Photo of Irvin Waldman

Irvin Waldman, Champion

  • 9,016 Points 5k badge 2x thumb
Hi Amr,

Review this post for a few ideas:  Numeric value validation on save.

Photo of Amr


  • 256 Points 250 badge 2x thumb
Thanks Irvin, the other post was sent was me as well :)
I considered this a different matter.
Photo of mB Pat Vachon

mB Pat Vachon, Champion

  • 43,056 Points 20k badge 2x thumb
I dunno. Sounds like something skuid should take care out of the box. Shouldn't need to setup a validation.
Photo of Rob Hatch

Rob Hatch, Official Rep

  • 44,448 Points 20k badge 2x thumb
At Skuid we'd prefer not to hijack the client side experience.  We so others actually disable the keyboard - except for valid keys.  This seems overkill to us.  So we try to handle intelligently the data entry mistakes by stripping out the offending code.  We also reccomend using Standard Salesforce validation rules (as you have already done in the post that Irvin links to above). 

If you want to implement client side validation - you can write a custom renderer,  but its not somthing that we are plannig to provide out of the box. 
Photo of mB Pat Vachon

mB Pat Vachon, Champion

  • 43,046 Points 20k badge 2x thumb
Can you do a how-to for this custom field rendering on video? 
Photo of Barry Schnell

Barry Schnell, Champion

  • 18,226 Points 10k badge 2x thumb
Hey Pat -

Sorry for the confusion.  What i meant is that SFDC standard page layouts allow you to input invalid data in a field.  It's not until save that it actually tells you that there is a problem.  This is all done without any validations as you said and what I was trying to say - just did a poor job of it :)

Regarding Skuid, the problem with having skuid allowing you to type anything (not stripping it like it currently does) and then leveraging built-in SFDC automatic validations (e.g. Error: Invalid number, etc.) is that skuid does a ton of stuff that enables other features to work.  This work is based on data being valid (or at least appearing valid).

Here's an example - Conditional Rendering.  Let's say that you have a conditional rendering rule that states to show a particular field (FieldB) if the value of another field (FieldA) is greater than 10.  If skuid allowed you to type "2 hello 3" in FieldA and didn't strip the invalid portion, each time it evaluated the conditional rendering rule, it would first have to check to see if the value of FieldA was numeric and then if it wasn't, how would it handle conditional rendering - should it show the field?  Hide the field?  By stripping the value, skuid ensures that the data is always the type expected and can avoid the problem all together.  If Skuid were to allow invalid data in a field, the performance hit would be very significant to other areas of the Skuid features since it would have to check the field value for everything it does - and trust me, under the covers, it does a ton of stuff based on field values.  :)  On top of the performance hit, the scenarios that it would need to handle (e.g. invalid data) would be large and handling all those scenarios in all situations would cause significant code bloat to the skuid code base which also would reduce page load performance, etc.  In short, there is a really good reason why skuid strips the invalid data :)

Now, should Skuid have a feature that allows input restrictions based on data type?  Sure, there is something to be said for that but that's really where the complexity of localization, etc. that I mentioned in my previous post comes in to play.  It's really a tough nut to crack and often very specialized to the application.

I'd agree that it would be great to have a way to do this that doesn't require javascript skills.  It is technically possible but comes at a significant "cost" - performance being the large component but also additional code which introduces risk to the skuid platform.

Personally, I'd love to see a declarative solution to this, would be super slick. Just don't see how the risk/reward for Skuid is justified given the all the above.  At the end of the day, it's only a few lines of javascript - a worthwhile trade-off for us as consumers I think.

Think of it this way, how many apps are built on SFDC that have zero lines of Apex written for them and use a 100% declarative approach?  I'm sure there are some out there but most applications have at least one trigger or VF page or something.  Javascript to Skuid is a kin to APEX for SFDC.  Besides, think of all the fun you've had learning javascript that you never would have had the opportunity to do if that were the case :)
Photo of mB Pat Vachon

mB Pat Vachon, Champion

  • 43,046 Points 20k badge 2x thumb
Oh my lord. I can only assume the example you layout in words is a good example. Personally I get lost trying to keep track of field A and field B. I immediately find myself in the "Who's on First" joke.
Photo of Barry Schnell

Barry Schnell, Champion

  • 18,226 Points 10k badge 2x thumb
Yeah, but who's on first? :)

Unfortunately, I can't do a video but here's the steps required and a sample page complete with the snippet.

Steps required:
1) Obtain Alphanumericplus from  You can substitute ANP for any other jQuery or javascript module or even write your own if you so desire.
2) Grab the jquery.alphanumericplus.1.0.2.js file and add as a static resource (e.g. call it AlphaNumericPlus) to your org
3) Create a new page using the page XML below
4) Test it out - Latitude field has renderer applied, longitude field does not

Page XML
<skuidpage unsavedchangeswarning="yes" showsidebar="true" showheader="true" tabtooverride="Account">   <models>
      <model id="Account" limit="1" query="true" createrowifnonefound="false" sobject="Account">
            <field id="Name"/>
            <field id="CreatedDate"/>
            <field id="BillingLatitude"/>
            <field id="BillingLongitude"/>
            <condition type="param" enclosevalueinquotes="true" operator="=" field="Id" value="id"/>
      <basicfieldeditor showsavecancel="false" showheader="true" model="Account" mode="read" buttonposition="" layout="">
            <column width="100%">
                  <section title="Basics" collapsible="no">
                        <field id="Name"/>
                        <field id="BillingLatitude" decimalplaces="" valuehalign="" type="CUSTOM" cssclass="" snippet="numericInputRendererSnippet"/>
                        <field id="BillingLongitude"/>
         <jsitem location="inline" name="numericRenderers" cachelocation="false" url="">(function(skuid){
var $ = skuid.$;
    skuid.snippet.registerSnippet('numericInputRendererSnippet', function(args) {
        var field = arguments[0],
            value = arguments[1],
            renderer = skuid.ui.fieldRenderers[field.metadata.displaytype],
            mode = field.mode;
// Run standard renderer for the current mode
// (applies to read/edit mode)
// if we are in edit mode, apply input control
if (mode === 'edit') {
      allow: '.-' // allow period (decimal point) and dash (negative)
      , onedecimal: true // only allow one decimal point
      , digitsafterdecimal: field.metadata.scale // how many digits after decimal based on field metadata
      , allownegative: true // allow negative number
         <jsitem location="staticresource" name="AlphaNumericPlus" cachelocation="false" url="">var params = arguments[0],
$ = skuid.$;
Photo of Rob Hatch

Rob Hatch, Official Rep

  • 44,448 Points 20k badge 2x thumb
Thanks for your detailed reflection Barry. And your proposed customization solution. All very interesting.