Time for some more fiddling with the elaborate API of the jQuery Editors helping you deliver awesome experiences! Here’s the quick jump list for the previous articles:

• jQuery Editors: How to get started and improve productivity and experience

• jQuery Editors: How to better guide users to the desired input

  • Simple input restriction

  • Masks

  • Validation and regular expressions

• jQuery Editors: Rich client experience (part 1)

  • Getting and Setting values
    • Form submit the AJAX way
  • Selecting editors and triggering validation
  • The multifunctional spin buttons
  • Style options

Still spinning

Well there’s one more trick you can do with the spin buttons and the dropdown too – you can make the editor read only (no not disabled like in the first article). The trick with read-only editor is that, yes – the field itself will not accept input, but the buttons still work just fine! And as you’d imagine there’s a property to allow interaction with those to still change the value and I also find useful the spin event to make it crystal clear to the user what happened exactly:

And the result of that is:

So, you can have an edit field and make sure without any need to check that the values can only go within a range and they can change by exactly as much as you want and in the meantime add a cool and helpful effect for the user (if you are changing the delta in runtime). Check out the demos – there you can find another field with spin buttons (showing the product category) and since that is just an ID and the actual category name is in a separate table, using events like this you can make calls to get the name of the category to display so the user can actually make sense of the numbers.

On a side note, to clarify the difference between this and disabled – when you disable all interactions are cut off, while a read-only input still can be given focus, interacted with and fire events and such.

A basic combo

I mentioned a few times so far you can create editors with dropdowns instead of spin buttons and they behave much like a basic combo box would with plenty of features. Let’s take the spin-button example from last article and use it with a dropdown. One neat trick is that when you provide the list of items it doesn't have to be strings – can be objects with ‘text’ property to be used instead. And if those objects happen to have a ‘getHtml(')’ method – the result of it will be the representation of the item in the combo. That means you can produce amazing template combos and still get the auto-complete functionality for text like you would with the spins:

The list of Infragistics products is obviously incomplete, it was random, sorry :\

Runtime localization

Except shipping you page/app with controls that are already set, the editors handle dynamic regional settings quite gracefully as well. To have access to the required localization resources you would need either the specific regional settings you’d want to use or form simplicity the whole bundle. For detailed information loop up the localization section in the Using JavaScript Resources in NetAdvantage for jQuery  and the Customizing the Localization of NetAdvantage for jQuery Controls one. For this simple case all that is needed is the resource file and I will just let the Loader figure when/where those should be placed. You can do that by adding a path to the file:

or use the intended regional property (and yes you can put the bundle ‘i18n’ file there too!):

Now you have all the local setting s available at any point and all editors can have regional settings and you can apply any at any point. With some event handling you can do that and achieve quite interesting results with some controls, like for example the Currency editor, which you can turn into a currency conversion field:

This is a-a-almost the full snippet needed to get this to work (just missing the loader from previous snippet :) ). Of course, as you can see the exchange rates are static (hey, they are up to date as of the moment of writing at least), but you can easily pull those from some currency exchange API out there. In this scenario values are actually fed to the editor in USD and that is the base value that is always retained – the rest are calculated from it and on change back to it when different regional is applied:

Make sure you check out one the demos and give this one a try yourself.

Enhancing the validation

Hiding the validation error message

I find this to be particularly useful, because error messages tend to stick around until valid value is entered, even when you don’t want to fix it right now. That’s especially annoying when you have other fields around stacked quite tightly (like I did) and that error message just gets in the way of something else. Not to worry! I have a small snippet to solve that globlally – hooking up to the igValidator event fired when the message is shown and setting a timer for it to be hidden!

The best part is since each editor initializes its own validator instance those timers don’t interfere with each other and since passing false makes the hide skip removing the specific CSS the editor remains with red borders to remind you that it’s still something wrong. A possible improvement on this would be to handle the focus event and show the message back then, not after another validation pass.

Making use of events

I have this quite lovely example (in my eyes at least, so bear with me) of a Mask editor functioning somewhat like a Hangman game, well, for the limited attempts at the very least. While this doesn’t entitrely have to be a copy-past kind of a deal, like you could use the message hiding, I do believe a more adaptive validation – being able to react to a certain number of bad attempts without the server participation is actually quite  - might be quite nice. This is to showcase the capabilities the events and their arguments give you. Here’s what we have:

Since when providing options for the validator those are added to the widget itself, you can in essence add your own, like I did here and use it as an internal counter, rather than keeping track of that in external variable(s). Also notice that this is the ‘check-value’ event, not the validation one. This happens before the value is evaluated, and well, you can do that yourself and if not to your liking, even though it would otherwise satisfy the rules, returning false will cause the validator to consider that invalid.

This method can be very useful to recreate real world validation purely on the client – limited number of attempts and when the user fails too many times you redirect him to a different page or display additional verification fields (The ‘prove you are human’ Twitter test, for example, load a Captcha..).

MVC  Gotcha-s

So besides the tricky part with all editors being of the base class type with the ASP.NET MVC helper and having the markup generated for you (which is sometimes different than you might assume), there’s some more quirks.

As you’d imagine you can’t go out of your way and add random attributes to the validator options with the helpers like it’s done above. You can still do it in simple script tag one the widget has been initialized. Also just for now you can’t really pass the ‘item lists’ array of objects as it kinda expects a List<string>.

One other notable gotcha – when dealing with regular expressions (and I might have totally missed that one before). By default the relevant validator property accepts both a string or the ready Regexp object. However MVC helpers, being helpful as they are, write strings to the document, therefore eating your escapes. And the parsing of the string to RegExp calls to string and it eats up another escape..so to speak. So if you are using sequences that need to be escaped once in a normal regular expression like ‘\b’ those must be escaped three times in the wrapper:

Basically this reaches the client as ‘\\b’ and after another call of toString() and up as the proper ‘\b’ to be converted to expression.

Demos and resources

• You can fiddle with two demos of your choosing:

- A JSFiddle demo, where the submit button is only good for triggering validation.

As always, you can follow us on Twitter @DamyanPetev and @Infragistics and stay in touch on Facebook, Google+ and LinkedIn! Stay tuned some pretty exciting stuff are happening for the next release!

TL;DR | Summary

Don’t say I didn’t warn about the jQuery Editors API – the fact is it’s quite a lot, it has to provide support for several different controls after all! As in the latest series you’ve seen how much you can tweak and drastically change the experience – rich client-side editing with no postbacks, flexible validation that you can even mix with your additional logic to create adaptive behavior, or make a behavior for invalid values. Even the little oddities of the ASP.NET helpers are no problem once you get to know them and perhaps we’ll continue soon with some more MVC editor fun..!