I’m working on adding some custom text fields to a few objects and just realized that skuid does not appear to enforce the max length of a field in the UI. For example, I have a text field with a max length of 3. When I add this field to my page, I can type more than 3 characters into it - it’s not until I hit save that I get any kind of error about the length.
Does skuid not detect the max length upfront? I’d rather users not even be able to enter more than the maximum characters allowed. I can probably handle this via a custom renderer, but that means I’ll need to use a custom renderer for most of my text fields. Is this on the roadmap for a future skuid release?
Hi Jonathan,
You’re right, as of yet, Skuid does not do this and it should. We’re thinking about implementing a whole client side validation framework in a future version of Skuid. However, we don’t have any timeframe on that yet. Just out of curiosity, if we did put a limit on the number of characters for an input based on the salesforce metadata, what would be your expected behavior if a user pasted in text longer than the limit? Should the text pasted be truncated? Or would you rather a “validation error” appear, immediately letting the user know there is an issue?
Hi Ben,
When I originally realized that skuid doesn’t currently support this, my initial reaction was that it should use the html5 maxlength attribute (which I would think would be easy for skuid to implement just this single tag, instead of writing a whole client side validation framework?). From what I’ve seen, any text that’s too long is always truncated - I primarily use Chrome, so I’m not sure if this varies between browsers, but I think that truncating the data would suffice. Here is an example page that truncates anything over the max length.
I definitely would NOT want the longer text to be pasted into the field though - that’s part of my frustration with how skuid currently works. Right now, I can paste or enter Y number of characters, but the field only allows X number - when the error is thrown about the length, there’s no easy way for a user to know where the length cuts off. That is, they’ll get an error saying they’ve gone over the max length, but there’s no good indication of where in their string that they hit the max length (are they 1 character over the limit or 500 characters over?). I think it’s cleaner & more consistent to never allow the max length to be exceeded: either through typing, or in copy-pasting.
Thanks Jonathan,
That makes sense. We’ll probably do what you suggest and use maxlength on inputs before we build out a client side validation framework.
Awesome, sounds great - looking forward to hopefully seeing this implemented in the future.
We got another request for this to be added as Jonathan described.
has this been implemented
