Being client-side controls I consider the editor widgets to have two major responsibilities  - take some of the load of the server by preventing invalid user input from ever reaching it (various performance enhancements)and at the same time do their best to filter/guide or even ‘enforce’ proper data entry (experience). Sounds familiar? That’s in the article in which I showed you how you can get started with the jQuery Editors and with that benefit from improved productivity and experience.

So the question is why would you have to guide user input in the first place?

I mean.. consider this - as with most web distributed systems (unless you are using your own communication protocols), you can never ever completely trust anything that comes from the ‘client’. And I’ll explain myself some more on this. The jQuery editors can’t really put an end to all the undesired input, JavaScript can only do as much. Plus, user agents provide consoles and script/markup manipulation right on the spot. Most defenses of such sort can be disregarded with great ease, really. You could go on and and make attempts to make it secure, but then again web requests are not exclusive to just browsers. And this is just intentional providing incorrect input (attempting hacking your app, put simply), however, even if you completely trust you users and say go as far as require client certificates with encryption.. well you never know when someone is going to hit the submit button after realizing he had made a typo or do so completely unaware the input is not supposed to be like that. Bottom line – you still have to do full validation of the received data on the server. So that’s part of the productivity gains from the editors that possibly applies in 99% of the time.

Now after that huge diversion I consider the productivity gains to be the smaller part of the benefits and the larger being the experience. Because what’s possibly more important is that in that 99% of the time the input can be controlled, filtered, hinted and a user won’t need to wait for a page reload to get a server message he did something wrong. And this includes all the filtering that some of the editor types do by default, the awesome masks for the igMaskEditor and the oh-so very flexible regular expressions supported by the rest.

Simple input restriction

Out of the box

As I mentioned and explained before, justifying their names the digit-related editors will simply ignore inappropriate values coming from both key strokes and value changes (read: pasting something in). As a matter of fact, some editors will go even further – the Numeric, Currency and Percent with set min value at/above zero will ignore the minus sign/dash even though they would normally allow it. Here’s an example setup:

And the initialization scripts:

From which you get two jQuery editors that only allow number input along with the current culture’s decimal separator sign. However when you try to enter a negative number:

In addition to that, those editors that would allow a dash(minus) will only allow it in front the actual number and will be allowed just once… so, yeah,  no phones in the field to enter money or quantity :)

Note: Also important is to mention that as expected from such controls when maximum and minimum values are defined they are enforced – you can think of this as another way input is restricted. Even when the user decides to enter an allowed, but unacceptable value, numeric-like editors will correct it to the minimum or maximum value. We’ll go deeper into that behavior in another article perhaps.

Conditionally preventing input

This has been asked by customers and I do believe it’s a valid point – in many cases editors need to be disabled for input until some condition is met – proper selection somewhere, valid input in another input in a chain entry situation. It’s really easy to implement – for the sake of the example we’ll use a checkbox to enable/disable to input and change the ‘disabled’ option available for all editors based on that:

When disabled the inputs won’t accept additional input and have grayed-out style applied:

Even though it might not be completely related, the editors also have ‘hide’ and ‘show’ methods – I suppose hiding an input when input in it is not to be allowed can be a kind of alternative to disabling.

Masks and hints

Of course, this is about the igMaskEditor and the help it can provide. The masks should feel fairly familiar to those that have previously used such functionality and easy enough to understand otherwise. They offer a rather wide variety as well as flexibility. With them you can sort of ‘mold’ the user input to a predefined template. They can be both obligatory (requiring input) and suggestive, the latter being of particular interest as they can very well serve as hints for the user. Besides actual input, the maks can also contain literals that can also provide helpful visual cues as to what is expected in that field. For example take the  very very standard telephone mask and lets see how we can solve the issue represented with the topmost image. Take a simple input:

And turn it into a Mask editor – the related property accepts a special string that contains both special(reserved) characters and literals:

Set up like that the editor will behave exactly like a date editor (strictly digits only with visual cues), because the 9 stands for optional digit:

I think it’s fair to say that this particular pattern is easily enough to recognize and serve as a guide for the user, while also applying restrictions.

But masks can do so much more than this! For example, take a name input field – you can capitalize the first letter for the user:

This way you can ensure the names will always start with a capital letter and when validation is used the name field won’t accept input less than two letters (‘L’ is the filter flag for a required letter, ‘?’ is optional letter). The greater than sign starts and stops capitalization and similarly the less than sign can make everything lower case.

Here’s a list of the rest of the filter flags accepted for a mask (everything else (or when escaped with "\\") is treated as literals, of course), in pairs (required/optional):

• ’&’ / ‘C’: any keyboard character
• ‘A’ / ’a’: letter or digit character
• ’L’ / ‘?’: letter character
• ’0’ / ’9’: digit character
• #: digit character or "+" or "_"

The complete list is available in the jQuery Mask Editor’s API reference under the “inputMask” property.

Again keep in mind that input in mask editors is quite pretty much forced into the template and literals are static as far as the user in concerned and can serve as either part of the actual value or simply as visual cues, depending on the data mode.

Validation and regular expressions

I cannot deny that for the purposes of guiding users validation is invaluable. I won’t go into much detail about the specifics of the igValidator (the one responsible  for the feature in the editors), but I will note a few interesting things that can be helpful in leading end users to the expected input. Of course, the most basic is showing an simple error message when something is wrong. However those are mostly generic (the default ones I mean) and could be made more useful with just the slightest effort on your side. For example if you simple enable the validation for the mask editor show above you will get the following error message:

That’s good and all, but unless you use “padChar” property to actually show the required fields this isn’t all that useful information. You can always override that message and provide the user with a description of what is expected or even provide additional examples, links and whatever you see fit really:

Yes, simple HTML works too, content is not encoded, so the result from the above looks quite nice:

When you can’t fit the mold.. regular expressions!

As the fair warning above mentioned, masks are just a s restrictive as they are useful. I’ve reached to this conclusion when attempting to create an editor for the Northwind () Product object and more specifically it’s quantity per unit field. Believe me, when I say I tried masks of all kinds, but none would fit quite right, because the field would contain values like “48 - 6 oz jars” and then “10 ba” or “10 boxes x 12 pieces”. That is quite diverse and you might be wondering “How am I to validate this? How to let the user know when something is wrong?”.

The answer is quite simple – all editors, except the igMaskEditor, will work happily with regular expression to validate the input. This is just about as awesome as it gets, because you get to keep all other functionality as is, but achieve tremendously more complicated validation on the user input and allow for such irregular input as the above with the flexibility regular expressions can give you! Let’s solve the above problem and we can do that with a simple igTextEditor:

To explain a bit – the regular expression will match a ‘word’ starting with a number and containign number only (no limit on length), followed by a space (literal) and then another word of letters only exactly after it. That means it will match things like ‘4 g’ and the second part of ‘200 – 205 g packs’:

JavaScript's RegExp Object will provide you the power to create extremely complicated rules and this way you can provide enough freedom to your end users to keep them happy and still detect and inform them when they need to do better. You can even do basic input fields for email:

You can expand this to be as flexible as required.. up to implementing the whole RFC specification if that’s your thing.

Demos and resources

• You can fiddle with two demos of your choosing:

- A JSFiddle demo, where you can go ahead and test everything described above instantly.

- An ASP.NET MVC project showing both setting up in script and using the Helpers. Keep in mind the MVC helpers do require the Infragistics MVC assembly, see below on how to get yourself one.

• You can lean more about the product and download free trial package on the NetAdvantage jQuery Home page.
• Make sure you visit the Editors’ online samples!
• Also if you need some help try our update Help page or dive directly into the Documentation and API!

As always, you can follow us on Twitter @DamyanPetev and @Infragistics and stay in touch on Facebook, Google+ and LinkedIn!

Summary

The jQuery Editors can truly make the editing and user input experience much better for the user, among other things. You have a plentiful toolset of editor types and settings that can control and  restrict and guide the end user to the desired input – editors accepting numeric values, just positive numbers. You can enable, disable or hide editors based on your own logic to achieve the editing results you want. The Mask editor offers a rich filter flag set to help you build a template for the users to follow and when that fails you can turn to complex regular expressions to know when the provided value is not valid and then also display a custom message to better explain the user what to do.