The Infragistics jQuery package comes complete with a range of editor widgets to help with one of the most common tasks  - gathering information from the user and making sure it is the one you need (validating it). Part of the product from day one – speaks just how essential they are. And in this blog and probably some more to follow  I’ll do my best to get you started and show ways to improve the editing experience and overall productivity, along with some tips and tricks. Collecting and filtering user input is one of those basic functionalities many platforms require and the jQuery version follows the path set by the type of experience provided by say ASP.NET Editors or XAML Inputs.

However, due to having both a client and server, web-based applications offer two separate points of opportunity to narrow down the unwanted input. So in such case the best place to start filtering input is on the client and the editors are ideal for that. More or less like the ASP.NET AXAJ counterpart the jQuery editors provide a similar set of controls – here’s the list:

• Numeric editor, itself extended by:
  • Currency editor
  • Percent editor
• Mask editor
• Date editor
  • Date Picker
• Text Editor

 

Before we dive into those, however, should be explained that all of them extend the base Editor class and use a Validator. Any extended editor can be created using the base Editor, should you need to, and any of the properties of the extended editors can be can be set within the igEditor. Of course, the whole point of the separate editors is to provide a mostly ready to use control with all the right defaults. So  further below you will see a logical representation of the editors hierarchy with short descriptions to help you figure out which one is the right for the situation.

The editors’ most basic functionality is, well… to allow a text field to be edited, not surprisingly, and to provide support for additional buttons for dropdown and such. However, the actual validation that is often a huge part of the process comes courtesy of the igValidator. Yup, it’s a separate widget which means you can use it stand-alone if you will on other Input, Textarea or Select elements. The editors use those for main element and initialize validators for you, of course. In the interest of having a complete piece of information, it’s probably worth mentioning the Validator is also used by the jQuery Combo and Rating controls.

Getting started

Resources

First things first – some resources are ”required: true”, so to speak. Nothing too complicated though, but if you are not familiar with how resources can be handled your first stop should be our Deployment Guide and more specifically the page discussing how to work with JavaScript resources. The most basic resource to add are the editors themselves and the validator:

or using the MVC helpers:

Editors

When instantiating the editors using just script you have to provide the actual markup (that being a container element or the actual input(s) to be transformed), for example:

and then you can initialize the widget like:

or using the MVC helpers(they will create all markup for you):

Of course, you can add quite a few more tweaking to those, but for now we are going for simple.

Getting values

To get actual values when you are submitting a form(see below or one for the demos for more complete layout) we include the additional ‘Input Name’ option. This has nothing to do with naming your input, even though the actual ‘name’ attribute of inputs is used by the browser when sending form data to the server. The option instead creates an additional field like this:

The reason is to separate the representation (the editor’s displayed value can be different – date formats, masks, literals, etc.) from the actual value – the editor creates this field and automatically updates its value to match the editor’s and this way you get the right data on the server. And the ‘onsubmit’ validation will prevent sending the form if the editor’s value is empty!

In the demo I have two date editors and the is the action in the ‘Home’ controles handling the form submit:

Of course, MVC does most of the value retrieval for you and some other helpful checks. One way or another this can be done on any platform!

Improve your pages’ input experience

Say you have a very common simple form for the user to fill in a few blanks. You can rely entirely on checking the result on the server but that is highly ineffective due to the completely uncontrolled user input and the additional round-trips to the server and back again. Then again as this is no new issue the HTML5 has added a whole plethora of input types to really ease that task and it’ll all be good… but none of the special features would work on IE8 or 7 and can be quite the show-stopper(not to mention the the patter to validate against in not supported at all in IE and Safari yet). So say you have the most simple form like so:

It doesn’t looks  or do anything special, really:

By all means, add all the HTML5 types to those, just keep in mind they will all fallback to simple text inputs for non-HTML5 browsers. As it has been a practice, the only reasonable solution is to rely on script validation on the client. Of course, you have the freedom and options to use anything. You can even attach an igValidator to those fields and get awesome results… OR simply turn those inputs into proper jQuery editor widgets. And it’s really simple too:

Basically you don’t need to change you markup at all in most cases (it’s  still the same HTML only swapped the description Input for a DIV so the editor can render its own main element instead). The user editing and input experience, however, is now changed drastically:

And by adding a single line with validator options ‘ validatorOptions: {}’ (can be empty for Mask Editors as their masks define required fields) will now also display an appropriate message when input doesn’t meet requirements:

The editors become the first line of filtering out inappropriate user input – preventing it from making a travel to the server and back, when it’s guaranteed to be rejected there. Save the server some work, help reduce pointless traffic and help the user by hinting the required input with mask prompt chars and messages.

Demos and resources

• You fiddle with two demos of your choosing:

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

- An ASP.NET MVC project showing both delimiting in script and using the Helper as well as the from summation handling in action. 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

As you’ve seen above the jQuery Editors are not rocket science to use, but can truly make a difference:

• Filter input, reduce server load/rejection rate and redundant traffic
• Enhanced editing experience
• User-friendly messages
• Completely customizable
• High control
• Rich API
• Stylable
• ThemeRoller compatible

And when you consider the benefits of the being able to use the editors regardless of HTML5 support, even on older IE versions and the wonderful capability of the MVC helpers to create validation based on your model’s MVC Data Annotations– you get a whole lot of functionality with little to no effort. Stay tuned for more jQuery Editors content coming very soon.

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 trustanything 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.

Once you get to know Infragistics’ set of jQuery Editors you begin to realize they are packed with various options and all sorts of knobs to be tweaked. It’s quite the rich API and it can be put to good use to create awesome client-side experience for the end-user. You get elaborate options, events and methods that will help you create functionality to delight or you can better adjust the editors to your page with styling and to your users with localization. That’s a lot of defaults and with just a little effort you can go even beyond that. We’ll take a look at some of the valuable methods and what you can do with them plus nifty events tricks; some combinations of default options that truly transform the editor and a DIY localized currency calculator field and more.

In case you missed the previous two articles on those here’s a quick jump list:

• 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

Getting and Setting values

So far in the first article you’ve seen simple form submit in action, which while doubtfully is a way of getting values... well, it has not much to do with the actual widgets, more with the HTML input element. That is default bowser functionality assigning key-value pairs using the form input fields’ name attributes. That is also the reason why we’ve seen an extra input and additional extra ‘inputName’ property – the second hidden input the editors use to set the actual value while displaying it in some odd format. Except that, the client side controls have little to do with the way from data gets to the server. This is something that can be changed and it’s next on the menu!

All the editors offer the value method that is used to both get and set data. Note that when setting a value, the widget will parse for you to the appropriate type depending on the editor ( e.g. number for numeric) and should it fail it will be considered invalid input and rejected. On the other hand, when using the method to get a value, you should be aware what you get would be dependent on the data mode for some controls (e.g mask or date editor). Fortunately, their data mode defaults are set up to allow you not to worry about that.

The value method:

That would return whatever value is currently in the editor as number. Yes, for simple numeric editors you can snatch the value directly from the HTML input, however, it will come as string. However take a Mask field with its data mode set to 'rawTextWithRequiredPromptsAndLiterals' and you get something quite different:

Same thing with igDateEditor and igDatePicker - they have a mask, of sorts, by default, so what you see is not what you get as the default value for those editors is a Date object, naturally. That leads to the following result from calling the value method:

Again, you need to be aware of those and change the data mode if the defaults don’t fit your needs. Setting values adds the new one as third parameter for the method:

NOTE: Passing an inappropriate value will possibly cause it to fail the parsing and come out as null. Also, if you suddenly feel a little mischievous and go for the HTML input value and set there something unacceptable, note that the editor will still be keeping the actual value and will restore it if needed upon first interaction. Just so you know..

Form submit the AJAX way

Again in comparison to the previous usage of form submit – the fact that it causes a postback in itself can be a somewhat of a user experience hiccup, definitely is for me. To address this, using the value method we can send all the values back to the server in a simple AJAX request and enjoy better page behavior  - no page reloads and if you bother to check for actual changes, reduced requests. Something that really helps when dealing with multiple editors, like I’m sure you would in a edit form, you get a bunch of different editor widgets with different names, which severely hinders the ability to loop through and collect values.

There are two solutions to this really – one being, if suitable, to pick all the values from the HTML inputs instead as they can be selected and looped through. I used this, because the receiving action in the ASP.NET MVC application handles casting the values back to their intended. Speaking of MVC, it is the MVC wrappers that can help a lot in this – for the sake of unified helper output code they initialize all editors with  the base ‘igEditor’ class and setting types. But then again that is so very much not a bad idea – using the wrappers and just in script if you define all editors like that it would be the base class used for all method calls so you would  easily be able to loop through and get the values in proper types too! Since all jQuery widgets store their data using the .data() method they can be accessed the very same way – you do need the widget name, and that’s why using the base editor makes this so easy, here’s a super simple method (more elaborate version is available in the demos):

Selecting just the right inputs completely depends on your own markup really - since this save function is used for editors created with the ASP.NET MVC helpers (they create a hidden input to store the value with the proper name for you)  I need to exclude those, as the actual widget is initialized on the visible input element. Also I have some radio-s that need to excluded as well. Then you also have something specific for the MVC helpers as well – editors with the spin buttons (they are SPAN elements) are wrapped in a parent span and the widget logically is initialized on it – thus the ‘.parent()’ call when the widget is not found on the input.

Being stubborn and all…

Once you get the widget reference you can access all options, properties and methods… validate as well! So yes, you are not in any way forced into form submitting to get proper validation going on. Also, to justify the title, in my script only demo part I have initialized each editor like I normally would with their extended versions. That, based on what I explained above, should make it rather impossible to loop through the widgets, or would it? The thing is you can still search for the widget reference, so what follows is a method that would search for all jQuery Editors in the selection and call validate on those found and return a bool if the group is valid (basically to be used to stop sending the values to the server, like a normal submit would):

Lines 4 through 6 would loop through all the property keys of the object returned by .data() and find the one that match the regular expression above (basically anything like ‘ig*Editor’ will pass) and take that key and use it to get the widget reference. The rest is simple call to validate and retaining false value if ever met, but the point is this way of getting the key can be reused for any functionality that seeks to find all the igEditor-s.

Invalid input behavior

One particular thing that I found different from other platforms’ editors is the lack of readily available invalid behavior (perhaps it can be added by popular demand, eh? what do you say?). Still the fact is that this can very well be achieved be handling the default editor events such as the ‘value changing’. Notice the ‘-ing’? Means this even can be canceled and if it is, well the actual change is as well! That means you can override the default set min/max value behavior by rejecting the input and leaving the old value instead!

Note that there are two ways to do that – cancel the change or change the value back. The latter can be used if you still want your ‘value changed’ to be fired.

Now with more… spinning!

One other favorite feature of mine  - the spin buttons. They are very easy to set up and provide quite the functionality out of the box. As you would expect for a numeric-like editor (Yes, yes, date editors included!) the spins with increment/decrement the value by one (the default for date is also one day). The spin buttons can help the end user quickly and sometimes more precisely get to the proper value. For that to happen, of course, the settings should match the usage scenario, but let’s say we want to go through a lot of values fast. The ‘spinDelta’ can be very helpful and the user can actually hold a spin button down and the speed as with value changes are applied gradually increases to a quite high rates!

Another extremely useful feature which you get out of the box – spin wrap around! What it does is when the user attempts to spin beyond the defined minimum and maximum values (normally that would do nothing), it allows that action to move to the other end of the value list – from max to min and the other way around, basically a rewind for the values. So lets improve on the editor code showed last by adding the spin buttons with all the enhanced functionality:

But wait, there’s more to these buttons:

Does that look awkward in any way? It looks like an editor with spin buttons but with text in the field?! Since this is a custom input implementation that does not use any part of the HTML input (of type number) the spins are not limited to just numbers! They can be instead used on even the simple text editor that has a list of items. Yes, that means you can provide a set of items and the user would be able to loop through them using the spin buttons. And wrap function works here(..and well you can change the button property to dropdown to get those in a list even, more on that in the future):

Style

As you might have notice the editors have been sporting some clean Modern design (why do I always feel like saying ‘Metro’?). Even with as little screen real estate as these controls take, you can still tell it’s pretty – sharp edges and colors, nice effects (especially of the validation messages and oh my don’t even get me started on the date picker). Go see them on the Editors Windows UI Theme Sample! And you can also use them with custom styles!

TL;DR | Summary

Stay tuned for the second part and DEMOS! When I mentioned something about a rich API it was no joke – so far some of the things showed above might’ve been more appropriate for the ‘guiding the user’ blog, but hey they just won’t fit, and at the end of the day those jQuery Editors’ job is to make both the user happy and the data reaching the server good, so almost everything overlaps.

So far we’ve covered how to get and set values, how to send them to the server without causing a postback via AJAX. Also on the list was how to get widget references for multiple editors and possibly using this to get values and/or validate them. I’ve mentioned some ASP.NET MVC specific differences that should be kept in mind, like events. The latter you can use to exercise better control over the way editors handle invalid input. You can also delight users with spin button functionality that would also work with predefined text values and and top it all off with some looks with themes and custom styles.

And I’m leaving some pretty neat tricks with localization and validation for the second part of jQuery Editors experience!

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

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.

- 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! 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..!

The XamSyntaxEditor is one of the recent additions to the Infragistics toolset. It made an odd voyage from being announced as a CTP not  with a release, but with a service release a bit over two months ago. And now it is on route to a XAML project near you, which was announced Brian Lagunas in What’s New in NetAdvantage for WPF & Silverlight 12.2: Part 1 – XAML Line of Business Controls.

A little bit on the side note – check out all the cool LoB stuff coming soon and make sure you don’t miss the What’s New in NetAdvantage for WPF & Silverlight 12.2: Part 2 – XAML Data Visualization Controls!

Now that you’ve got your basics lets jump into more details and examples.

Quick setup

First things first – you will need the references to the required assemblies and either the latest service release of either NetAdvantage for Silverlight or WPF. If you are lazy like me just take advantage of the new search bar in Visual Studio 2012 (search field in every place imaginable, yes! yes! Thank you Microsoft!):

Now in case you don’t feel like using a toolbox – the list includes the base platform assembly, “*.Undo.v12.2”, “*.Documents.TextDocument.v12.2” and “*.Controls.Editors.XamSyntaxEditor.v12.2”.

At this point you can setup the Syntax editor in both XAML and in code. (Note: Since the editor won’t do much without a document I consider them a unity and therefore setting up the editor also includes adding in the document). In the absolute most basic case your editor would look like so in XAML:

And in C#:

Important thing to keep in mind – the Text Document is responsible for the desired language interaction(highlighting and error validation) and it’s default setting is ‘Plain Text’. That as you can imagine does not support either of the previously mentioned two very important features, so to get them you might want to set a language using the language property:

Out of the box the editor also supports VB.NET. Of course you can set the very same property identically in XAML and run the app and you’ll get:

*Random C# code pasted form the code behind not included.

The last line is where I deleted a semicolon and a closing parenthesis so now you the familiar squiggly underlines in red are there to indicate something is indeed wrong. And language key words are colorized in nice blue as expected.

What’s in the box?

Grammar

Back in the "What’s new” post – did you notice Syntax Parsing Engine? If you did then +1 for you! Yup, the lexer is actually an autonomous engine that is part of the core experience the Editor control provides. It is responsible for the parsing, creating of syntax tree and error reporting. As mentioned it does come with support for  plain text, C# and VB.NET, but most importantly EBNF(Extended Backus–Naur Form) so you can add additional language descriptions, but on that some other time.

Clipboard support and Undo/redo manager

Also by default the Syntax editor comes with clipboard support for all common actions and also support for unlimited undo/redo operations. Does that sound familiar? Remember the not so long ago introduced Undo / Redo Framework for XAML applications? Yup – it is right here with all it’s features – the unlimited operations stack of Undo Units, flexibility, etc. You can set up properties of the manager from the property of the Text Document:

Text Documents , Snapshots and Scanners

You might actually see this as the TextDocument framework, where the document represents a single text file and supports languages and operations like Load and Save, Append, Delete, Find and Replace and Insert and quite a lot more! It that you have (among other ways) a snapshot and the TextDocumentSnaphot represents the entire state (i.e. version) of a document. Every time a change is made to the document a new snapshot is created. Each snapshot is thread-safe and immutable. The snapshot provides access to lines, length, search method and a one to create a scanner. TextDocumentSnapshotScanner class targets a specific instance of a TextDocumentSnaphot and is created via the snapshot’s CreateScanner method. It provides neat methods to navigate between lines, words and tokens.

As you can tell the XamSyntaxEditor is quite the composite control but is it also very flexible and extensible. It strives to provide Editing experience much like the one you have in Visual Studio and just like it implements APIs that are familiar to Visual Studio extension writers.

Splitting and visual cues

If you have noticed above in the screenshot this is the Editor in Metro/Modern/Win8 style (seriously, got all confused lately!). Even though it doesn’t really have that much UI, there are still scroll bars and.. two odd rectangles. What I can’t show you on a screenshot is the mouse cue you get when on top of it as it prompts for resizing. That is because those are handles to drag and actually split the view!

*Sorry for the slightly large gif and slightly buggy recording :)

Both views are scrollable and maintain their own selection. The editor also has property to allow some or none of the splitting options to the end-user.

Commanding

The XamSyntaxEditor comes with a substantial set of commands! I mean there’s a list and it’s kind of long. From default things like Cut/Copy and Paste to split or moving the view in various directions to Undo manager commands and even to upper or lower case and selection. It’s a rich choice and I’ll just show you a small example of a two ButtonTools (consider them to be normal buttons if you will) on a XamRibbon:

The syntax commanding source above contains all the command types I mentioned and probably some more.

Loading and Saving

The Syntax Editor’s Document is the one with the methods to load and save and both methods provide overloads to use either a string with the file name or a stream (the save method actually offers a few variations that can instead save using information from a previous call to the load method. I’ll throw a two fast examples of how to save locally but load from a remote file:

More!

There’s really so much more you can do as I mentioned the control is designed to be extensible, so once you gain substantial knowledge of the control you can customize it quite a bit. For now I’ll tease you with my pretty app where I have the above file loaded, the save, the commands in a ribbon , along with a search fields and a status bar with info bound to the Caret position for example:

And it looks and functions wonderfully:

Stay tuned

This has obviously barely scratched the surface but it’s enough to get you started, provide basic info for the XAML Syntax Editor and show you some of the interesting commands, load and save methods and other properties.

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!

The XAML Syntax Editor is pretty awesome control – I mean being able to create your own code editor is one and then just customize language and coloring and… add the fact that you can split the view and be on at line 50 and 500 at the same time and making changes in both spots! As you can tell, there are still plenty of neat things about the XamSyntaxEditor that I’d like to show you. I  showed you last time how to get started with this cross-platform control and with some basics covered lets dive into the options to customize and enhance the functionality and user experience of the control.

First to mention that even though the v2 release for 2012 is not yet out, you can still go grab the CTP version – download links can be found in Brian’s announcing post. Besides major spoilers on what features are to expected in the future, in the downloads you will find samples! But most importantly you can check out the XamSyntaxEditorStudio demo that features something similar to what I’d like to show you today and some other cool tricks:

Even by looking at it by adding Find and Error panes it does feel Visual Studio-ish and that’s the goal.

Custom Margins

I’ll just mention this somewhat briefly to acknowledge it is there. The feature is actually the one providing for the line numbering and behave in much the same way – fixed/frozen/static/pinned area (man, I’ve seem a few variations of having something just not scroll along). And when you go for a custom margin you define the content and position –  top, left, right and bottom. The Syntax Editor allows for a large number of margins, but my guess is that, yes, you can cover your entire code window in margins but what good would that do? Personal advice – don’t go wild on the margins, one or two should be enough. Examples of how this works you can find in the samples I mentioned above and it kind of looks like this (squished):

You will find this pretty well described in the upcoming documentation as well.

Colors and Typefaces!

Naturally as you’d expect form an Editor you can control a whole bunch of visual properties… and then some. For one you can customize the line numbering margin text with properties exposed directly in the editor and those include font family, style, weight and color. On a side note selection highlighting colors are also exposed as properties for you to tweak. Now, let’s assume I’d like me some Segoe UI numbers to match the system and I wouldn’t mind to have those in just slightly darker blue. But now my numbers are Segoe and the code is Consolas (Visual Studio’s default) and I’d like those to match. Even though by default the font is set to Segoe UI for me it didn’t take that seriously until explicitly defined:

I gave the margin some gray background to match the ribbon and to be more clearly separated from the main view. As you can tell with font and background changes you can achieve that ‘dark theme’ look you can see in the XamSyntaxEditorStudio and I see on so many screens with VS.

Better yet..

There are other colors the editor does well – the syntax highlights! And you can very easily tap into those as well. And since there are quite a few language elements I’ll just mention you can tweak most. The control accepts a ClassificationAppearanceMap object to keep track of those modifications:

As you can see you can add to the map by specifying a type key which can be a language keyword, but can also be comment, identifier, operator, number and so on. Even the SyntaxError is here so you can change how that looks too. In my example above I just made keywords a bit larger and in darker steel-blue tone.. it doesn’t look all too amazing so no screenie.

All those layers

The Editor displays content in four (five?) dedicated layers. You have the background as bottom layer and the caret(yup it has its own) as topmost. In-between there’s a text layer, one for selection and one for syntax errors. And then you can add you own implementing the ISupportPositioning interface and render content on any.

Now you could ask what kind of content would you be rendering? Answer is hiding below somewhere..

Search, Find and Destr… Replace!

So here’s what I did – I went on and added two inputs to enter search criteria and replace text with the following method:

Sure it works great and it even does the same as VS showing the message with how many words you just lost :)

But at this point I want to have a simple search and feeding empty string or even null instead replacement text are no options(one deletes every match and the other plain errors out). And then the Document has no simple search? Of course it does! The ‘Find All’ is actually in the current document snapshot. And since you get a collection of results, why not do something useful with it? The sample above goes to display the results in a box and move the caret to any of those. I’d like to iterate on that and mimic most editors’ behavior by providing navigation between results and ended up with this search utility or manager if you will:

As you can see there’s even an event (that is connected with the next enhancement) and methods to perform search, navigate between the results back and forth and clear them. So with a simple input and two buttons this will achieve the following:

Note: By default Case Sensitive and Match whole word options are off. Also I think it’s fairly clear I’m selecting the next word rather than the exact match. I think it makes sense with some more visual from below…plus it makes my life easier as the Selection Manager provides a whole bunch of methods to select up and down, till end of line or even end of text and of course a single character, so the word is a quick and dirty solution.

Custom Adornments

There’s still something missing I feel, still not enough visual oomph . I like it when some editors highlight every match and this is exactly what I want and thanks to all those layers I can have highlights. Adornments are just the tool to get my content on those layers and guess what – selection itself is one and so are the syntax error lines. The editor comes with base generator and provider classes to extend. Providers are registered with the control and their method called when a new generator is needed (basically for every new document view and yes, works out of the box with split views). The latter are created to provide adorners for particular layer defined at initialization. If you notice below while calling the base constructor the background layer is picked (we don’t want those highlights to mess with anything else):

Search results are still stored in the Search utility and the event is used to trigger the highlighting on search rather than just the default layout changed with the document view. The base generator provides the respective layer to which you can add your adornment in the form of any UI element really. Overriding the OnRefresh and OnUnload is somewhat optional, but recommended. The OnRefresh is called from the editor in case some external property that can affect adornment is changed that doesn’t necessary fire the layout changed. And the unload occurs either on unregister or every time the document loads now content (which in my case happens as I initialize with nothing and then load remote text). The base methods won’t do the cleaning up for you. Speaking of unregister, here’s how you register first:

With this you get experience that is just like when you add ReSharper to Visual Studio and your searches now highlight all matches and you can navigate them! Well, in all fairness, my yellow is a bit off and I select a whole word no matter what, but those are two tiny details that can easily be tweaked to your liking :)

TL;DR | Summary

I’d like to end like I did the last time and that is by stating there is more and more to the control that I can manage to display. We took a brief look on how can margins be added to the control and tweaking various text elements. We also enhanced the search functionality by adding selection and neat navigation and topped that off with awesome highlights with custom adornment. I’m quite happy how they turned out and just as a tip you can use this approach to add any kind of visuals to your editor, just don’t go crazy on the drawing as it could get intensive.

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

An all new functionality with the second release for this year comes to bring more flexibility to your grid and the way it handles data. The unbound column is one of the classic grid features throughout Infragistics experience with grids and now user demands are met by the all-new-yet-same Ignite UI Grid :)

The feature itself allows for columns that can be used to render separate arbitrary list of items or calculated values usually based on other columns’ values. The columns support and work with all grid features – proper sorting, filtering, etc. Also normal column enhancements like column templates, formatters and any other column property are available. It is very simple in concept and then once you get a closer look and take into account how this would interact with features it can get quite complicated, but that would be something to dive into later on.

Why Unbound columns?

What good are they for? For one, imagine a situation I end up in quite often – I like using Entity Framework but when I reach to the part where data needs to be send to the client all hell breaks loose. Why on earth has this not been addressed is beyond me but the Entity objects are damn near impossible for the default serializers and this has been around for so long. So what you do is either go for third party ones or use Data Transfer objects that are meant for such cases and that works good for me most of the time and it reduces traffic too. In those cases when one data model is not enough and out of you control, for when you need data from different sources and the Mashup Data Source is too much hassle or you don’t even have some parts available when the grid is created… this is when an unbound column can totally save the day.

Then again that is not all – besides integrating two pieces of data, the unbound columns can be used to display completely new data. You can use the formula property to calculate values based on other values in the row. That means you can now create Summaries on per row basis, rather than the out-of-the-box ones for columns!

Quick setup

At first glance the unbound columns are no harder to define that any other -  as mentioned, all properties are available and features behave as expected. The single most important difference is the ‘unbound’ property that you can set to true in order for that particular column to be omitted when binding to the data source. Essentially you can get an empty column with no relation to the data model:

To put things in perspective, here’s the full grid definition.

And the result of this is:

As you can see you get a column of whatever type you have defined and the filter criteria match that too.

ASP.NET MVC

The helpers provided with the product could always be used instead to help you generate the same output with great ease. You actually have two options when using the server side assembly – chaining syntax with the HTML helper alone or combined with the grid model. Let’s see how that’s done. With just the helper in which case the model passed by the controller is the actual data:

Or using the grind model where the latter is being passed to the view:

And that is merely consumed in the view:

Note: While the result will generally be the same, the above grid model is missing feature definitions just for this snippet. Also all snippets so far assume you are aware scripts need to be loaded in advance either manually or using the Infragistics resource loader widget. For full code refer to the demos themselves or general help with proper setup can be found in the Deployment Guide in our online help.

“So now how do I get data in there?”

That’s the logical question that follows. You have a column completely unrelated to your data model but it’s empty and that’s not why it’s there. Rest assured, you are quire in luck when it comes to options to supply values for those type of columns.

Unbound Values

So now comes the part I mentioned with model serialization and DTOs. The simple task of displaying AdventureWorks () Employees that has no names also requires the Person table. For the sake of the example imagine you don’t have access to the model OR those are in separate databases even. So the grid is bound to the ‘Employees’ and since I only want the names from ‘People’ I provide them in a separate list.

ASP.NET MVC

Keep in mind the list can be absolutely anything, really from values from remote APIs to calculated or generated values. Next in the view we have same grid definition as above with the addition of using the ‘UnboundValues’ option:

And using the model (you can see the :

Of course, those server side properties are proxy to the client API where you can use it like so:

Note: When using the ‘UnboundValues’ property the list of provided values is assigned as is – meaning is the same order, which means that those *must* be ordered the same way as the data source if you want meaningful results.

Set Unbound Values

The very same result can be achieved using the ‘SetUnboundValues’ grid method. With it you can provide values for any columns by specifying its key:

The method is also available with chaining and it has two overloads – one accepting as second parameter either a value list like so far or a dictionary with primary key and value pairs. The latter naturally requires your grid to have a primary key defined and if that is the case it is the recommended method to use as it’s the end result of the other overload anyway (yes, by all means, read that as performance gain). This can also spare you the hassle of having to order your sources the same way because using the Dictionary overload you can essentially assign value for each primary key. So for the above ‘peopleNames’ you can now use something like:

NOTE: While the unbound column itself may not support some remote feature (see below), other columns normally would and their results affect the entire data view and for correct results you absolutely need a proper mapping between unbound values and the grid’s primary key, therefore the above Dictionary overload of the ‘SetUnboundValues’ method is always the best option to be used.

As always things in client-side script are much less constrained and also somewhat different in functionality as it’s executed after the control is initialized. You can do that either in grid events or user triggered actions. For a start the easiest way is to go for a button click:

Note: The client version of the method as you can see takes values first and then the key and can be called after the grid is initialized regardless of the unbound column state – be it still empty or already initialized with values, so this can be combined with the previous resulting in a prefilled on the server column and just the first few values replaced by the method:

Formula

The probably most exciting part. It’s not really even a formula per se. It’s a JavaScript function that is called with the rest of the row data and reference to the grid so it can calculate and return a value for the unbound column. However, since it’s just a client function you can return pretty much anything and obtain it in any way. That is powerful. Here’s the most basic usage I mentioned making some kind of row summary if you will. Inside the grid column definitions:

Note that the row is pretty much the current data record even with the ‘name’ unbound value we already have. Also the formula property can be set with string, which I’m sure you will see when using the identical MVC property:

The result of this is the heading screenshot of course.

Gotcha-s

As I explained it’s a deceptively simple feature and once you look into it it’s quite something. That warrants a few limitations. While it does work just fine on the client with every feature, the server side compatibility is lacking – in fact, remote Filtering, Sorting and GroupBy are not supported for unbound columns. You could potentially perform updating but as you can imagine the rows (grid records) no longer match the server model the grid was bound to so custom deserialization would be required.

There’s also the matter of how the additional data is to be handled and that is dictated by the ‘mergeUnboundColumns’ property. There are some performance implications to this that we’ll leave for some other time (read: the second blog, find directs links to skip to that below).

Resources and demos

• How to configure jQuery Grid Unbound Column and make the most of it
  • Merge Unbound Columns property and Performance implications
  • Merging Unbound Columns and setting values on data-bound client event
  • Client-side methods to get Unbound columns and their values
  • Using unbound columns with advanced column options such as Templating or formatting.

• You can instantly try the the feature with this JSFiddle demonstrating different ways to set unbound values.
• A shared demo for this and the previous blog – and ASP.NET MVC project with various grid configurations described so far. Keep in mind most views use the MVC wrapper and require at least a trial version of Ignite UI on your machine – click the banner below to get yourself one.
• There are two demos available in our Samples: Unbound Column in the Grid and Unbound Column in the Hierarchical Grid.
• You can find general and control specific help in our Online Documentation
• You can find the client-side options and methods in the Ignite UI jQuery Grid API reference.

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

TL;DR | Summary

We’ve looked into the benefits and different applications of the all new Unbound Columns feature in the Ignite UI jQuery Grid. We’ve went through adding such a column to the grid and the different ways to provide it with data in both client-side scripts and using the ASP.NET MVC server-side helper/wrapper. We noted some cases to in mind and in a following blog we’ll go into greater detail about the ‘mergeUnboundColumns’ property and also methods to get values from unbound columns.

When in need of displaying columns with separate data – be it from a different source or based on the values of others – this new column type will prove truly helpful. Be sure to read the introductory blog on how to get started with jQuery Grid Unbound Columns. As promised we’ll go into greater detail into the options available to tweak the Ignite UI Grid’s Unbound Column feature to your own use case and needs.

Merge Unbound Columns

This is where it really gets interesting. Due to the very nature of the performed functions – bringing two or more distinct sources together in a single control’s view -  as a developer you are given a additional option to control that. You can define the grid’s behavior  using the MergeUnboundColumns property. It is relevant when defining a grid on  the server-side with the ASP.NET MVC wrapper. The default option is false and what happens is that your unbound values get sent to the client as Metadata, rather than along with the actual data source records. You can take for example the previous blog sample. To make it clear here is how a part of the grid definition would look with the option off by default :

(It’s a little bit formatted and the actual records are collapsed so the structure can be visible, but rest assured they do not contain any of the unbound values)

Of course, if you take a closer look at the generated scripts you will also notice the above grid being initialized with the identical client property ‘mergeUnboundColumns’ being false. I did say it was a property meaningful when using the ASP.NET MVC helpers and it mostly is. What the client property does is being a flag for the grid if the data comes merged..or should the control do that on the client-side only in combination with remote data source. Otherwise, this property with local source won’t have any effect whatsoever. What all this means is that at the end of the journey the widget will have to do the merging anyway – that is how such values can normally participate in features such as sorting, filtering, etc.

Naturally, what makes the difference when setting this property to true is that the merging is performed on the server. Notice line 2 below:

As a result data gets send as a totally normal set of records and the merge client property states true telling the widget not to look for values in the metadata as they are no longer there:

Merged Unbound columns distinctive property – unboundDS

The “unboundDS” property indicates that the column is indeed unbound. This is done, regardless of the client treating unbound columns as bound when ‘mergeUnboundColumns’ is true. Or should I say this is done exactly because of that. Have a look at what comes as a column definition in this case:

As the values for the column are already in the records the grid is not supposed to look for them elsewhere and the unbound setting is false. But then again the same false can be added to any other column with no side effects..So how do you know if there are actual unbound columns defined anyway? This is why the ‘unboundDS’ property is here for, to give a way for a client code to know if and which columns’ values are separate and most importantly to inform the grid that remote operations such as filtering and sorting (not supported by the feature) should not be allowed for that column.

Performance

As you can  see the above-described configuration produces mostly the same results, however this time the served had to do the heavy lifting and the client enjoys not having anything to do with this and being blissfully unaware of unbound values. This is also very important as you have the option to distribute the load between client and server. Then again a fair warning follows – merging on either side may result in a performance hit if the original data source is way too big. This is because the whole data must be traversed and new unbound values added to it (or default null values if the list values are less). As you can imagine though, the server is usually the one is a more dangerous position as the large data manipulations can become pretty a serious problem when they have to be performed multiple times for multiple clients. A client doing this instead should take much less of an impact doing just its own work.

On a side note, remember the Set Unbound Values methods discussed in the previous blog and how it is strongly advisable to use the Dictionary overload as it is a performance gain? Well it’s even more true when using the merge option on the server - causes even more work as the server will be otherwise forced to create the bindings between values you provide and primary keys available. Of course, you are best to save it the trouble and assign them yourself, plus that way the order of the values won’t matter as much.

Client-side data manipulation

Last time we demonstrated the client-side version of the method to set unbound values and saw the additional route of applying a formula on the client. However, those are not the only ways to set unbound values. There’s also an interesting turn of events regarding the usage of the so far described merge functionality that requires some additional client work and therefore, being well equipped to manipulate data on the client is never a bad thing. 

Merging Unbound Columns and setting values on data-bound client event

Let’s have an identical example as so far but this time lets enable the merge option along with using the formula field from last time. Nothing special it shouldn’t affect the end result, right?

Well it did…

See when merge is enabled essentially you tell the grid values will be provided on/from the server and a JavaScript function for the formula is definitely not that. Also since as I explained values are assigned with null as default… that is what you end up getting this way. Can you still provide the same functionality with merged unbound columns? Sure! It’s not quite as simple, but possibly the most appropriate way to do this is to handle the client ‘dataBound’ event, at which point will have the data source object ready and you can directly assign values for unbound columns. Here’s the old formula function:

All that’s different is that you don’t have a function called each time with row values, but you can make it work again(if it was something big that you would not want to change or refactor):

Once more, the data-bound event is the most logical place to execute that code as you have the data source, but the UI is not yet rendered, therefore this solution creates exactly the same results as before without noticeable difference for the end-user. Even so, it’s worth mentioning that you can enforce this method of assigning unbound values directly into the source at any point after this as an alternative to the SetUnboundValues method.

Get them!

Speaking of ‘SetUnboundValues ‘ the opposite operation is also available as a client method. There’s also a method to get the whole column even:

The first provides you with the whole column with it’s properties and values:

And the values only method will give you just that array of values, however the column key parameter is optional and if not defined an object with all unbound columns’ value arrays will be returned instead.

It’s Complicated

Or is it? There are a number of questions in regard to what happens with unbound columns and advanced column features you’d normally use. This is especially true when you have a formula defined as well… well you can rest assured the functionality is all there. In the very special case of formula calculations to get the value – it is called before any formatting function or applying a template so for all intents and purposes it will work as with any other column. Just the column definition:

And it’s all working pretty well:

Same goes for formatter functions that are the more extended functionality, but largely similar to templating.

Resources and demos

• How to get started with jQuery Grid Unbound Columns

  • Why Unbound columns?

  • Quick setup + with ASP.NET MVC wrapper

  • Adding data:  with the UnboundValues property, Set Unbound Values methods and calculating them via formula.

• Two JSFiddle-s available for you to play with – the previous one and another built on top with added support for getting unbound values from columns and conditional templating discussed in this blog.
• A shared demo for this and the previous blog – and ASP.NET MVC project with various grid configurations described so far. Keep in mind most views use the MVC wrapper and require at least a trial version of Ignite UI on your machine – click the banner below to get yourself one.
• There are two demos available in our Samples: Unbound Column in the Grid and Unbound Column in the Hierarchical Grid.
• You can find general and control specific help in our Online Documentation
• You can find the client-side options and methods in the  Ignite UI jQuery Grid API reference.

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

TL;DR | Summary

In this article we covered the usage of the Merge Unbound Columns property and its vary important performance implications. A look at the inner workings of the grid’s server model provided some insight on what’s really happening and how that would affect your application. Furthermore, we saw how the merge can affect functionality such as the formula and how to overcome that, along with some additional client-side manipulation. Hopefully the blog also cleared any possible questions as to whether Unbound columns work well with other  Ignite UI Grid column options such as formatter functions or templates.

I’ll end this in a manner similar to how it was started – saying that such a feature concerning something as underlying as columns types in the jQuery Grid can affect multiple behaviors and features and is by a long shot not a simple functionality, as I hope it has been made clear by now. For that reason, there are still more interesting topics to be discussed for the future.

Unbound Columns bring you the freedom of flexible layouts in the IgniteUI Grid and neat support for features to make your grid behave like nothing’s that different.  After you’ve seen some of the capabilities (getting started blog) and inner workings(configure and make the most of it) it’s only natural to tackle some not too basic cases. We’ll throw in some editing action – in all fairness, something very basic as far as the user or desired end-result are concerned, however nothing simple in the eyes of the developer. Following that some curious scenarios when using the Hierarchical Grid with unbound columns. So let’s jump right on topic.

To Save or not to Save

Custom Deserialization

Adding Updating should be fairly straight-forward, but there’s a catch.. or rather a few. One thing you are extremely likely to face is handling updates to the server. The grid will behave as expected and kindly include unbound values in the transactions. For that reason, as we already mentioned. the client-side model that includes Unbound columns would not match the one the grid was bound to on the server. That means direct deserialization using the standard .NET serializators won't go very well(more like at all) and the same goes for using the Grid model's LoadTransactions method(which is the same thing really). The most reasonable way to go about this is custom deserialization. Don’t let that fool you – it’s actually very easy with something like Json.NET. Plus, it even comes pre-packed with some (all?) new MVC4 templates anyway. It’s fast and, as far as my experience goes, it handles missing or extra values easily. Let’s have the following Grid configuration with AdventureWorks () Employees similar to so far used examples:

Or the equivalent in ASP.NET MVC using the helper with chaining:

As you can see the ID is not editable for obvious reasons and so is the formula field. What you would get from the grid as a transaction would contain all of the above properties. One approach would be to take advantage of the flexibility of Json.Net and go about it as you normally would:

Form there on it is identical to what you can find in the documentation on Batch Updating. Another take would be to go for LINQ to JSON instead and deserialize to JObject:

An advantage you get is that if you like me don’t have the whole model displayed in the grid and therefore the transactions don’t contain quite the whole records and assigning it blindly will just put nulls in the ones I’m missing. Besides picking separate properties from the record this approach is also the easiest way to access unbound values if you need them:

“My Unbound values don’t reach the server”

So you use the client-side ‘setUnboundValues()’ method like you are supposed to and attempt to save the changes with the method above but they never appear to persist. What gives? Well, for starters “you are supposed to” in the last sentence is truly wrong – the method does set values but since it’s designed to work without updating on the grid, the changes it makes are “client-side only” type and are completely unrelated with Updating and transactions. That means that you are setting a value but it is never sent to the server or persisted in other way. So to achieve the desired result you should turn to the Updating API instead and use either ‘setCellValue’ or ‘updateRow’. Yes, they work work with Unbound columns! Frankly, the methods have very subtle differences with  the main one being the type of transaction they generate and I usually pick the one that matches the edit mode:

There basically produce the same result with different type of transaction. In the demo and the JFiddle versions linked below I’ve put up a simple demonstration of this with a log you can use to list the current transactions on the grid in order to see that there are indeed none after a ‘setUnboundValues()’ call but the Updating methods behave as expected.

Formula Trouble

So you save  your changes and everything obviously goes well with the server, but ..

Find something wrong? This is a row in which I’ve edited the Vacation hours value, however the total value calculated from a formula stays the same and moreover, it’s the same after the actual submit of transaction to the server passes too. Because of the type of functionality formula property – it is neither a template nor a formatting function, it’s supposed to provide the initial value. Therefore, it’s called on binding and from there on the grid has data to work with as if it is part of the data source and formula is no longer needed. But hey, I want my value correct and I don’t feel like reloading the page for sure. So how do you get this to work? Consider this, the save changes method does not offer a callback and in case you are wondering neither does the original in the igDataSource. But it does say AJAX and it should have a callback, right? And it does, lets just say it’s well hidden. It’s called a success handler and the grid maintains an array of them to call when it handles the AJAX success (only!). Also the problem is I want to refresh my view in order to update the formula calculations. However, simply calling ‘dataBind()’ on the data source won’t do in my case as I have additional unbound values(the names) that are still the same and they won’t update until a refresh of the page. Plus, it's a lot of overhead I don't really need(goodness forbid using the grid's data bind method that does a whole lot more work even). Thankfully you have grid operations that cause a re-bind such as paging and sorting without messing with the actual data in the source. What if we could use that? Well we can! A slight hack if you will would be to trick the grid into changing page without actually changing it which would essentially be a page re-fresh. This can be done using the ‘pageIndex()’ data source method you'd normally use to programmatically change page or get current index:

This registers your own handler that gets the very same parameters as a normal AXAJ callback (and this can be useful in many other scenarios!) and in it we access the grid’s data source now that we know that the save has gone through and do our little refresh inception-style. It’s not perfect, but it kind of works; another very plausible solution would be to just go ahead and set the right value.

NOTE: Keep in mind that if you use template to display value in unbound column that is built with values from other columns it will update once they change. There’s a demo available for that in both MVC and JFiddle below.

Hierarchical Grid with Unbound Columns

Now here’s another good one. By design the hierarchical grid uses flat igGrids and for that reason we consider most of the functionality  to be shared and used in the same way with the same results. However, there are a few logical, yet important differences to consider when using hierarchy with Unbound Columns.

Setting values and child column layouts

Of course, all the methods to do that are still available, but consider this – you now have not just one grid, but rather a whole bunch of them. Using the ‘unboundValues’ is mostly logical as they are tied to their column definitions. But when you decide to set some unbound values on the client but nothing happens? For reference here’s how the grid definition looks:

And to sill some of the missing values you attempt calling something like:

However nothing happens. If you had attempted the same with say ‘employees’ it would’ve. That is because as we explained there are multiple grids here and set value methods are to be called for the respective layout. So in order to add values to the child layout you need to access it first. The hierarchical grid provides a method to do that:

You could pick one, but above I’m targeting all available child grids and setting values and there’s a good reason. To be able to target specific layout you need to be aware it is there – the Hierarchical grid creates the child grids only when expanding for performance reasons, therefore you cannot set values to something that doesn’t exist yet. Furthermore, unless you provide you unbound values in advance ( set them on the column property or merge them on the server) even after calling the above, newly expanded(created) layouts will still be with empty unbound columns. My best advice is to assign even temporary initial values to spare the user the sight of empty columns and/or handle a suitable event such as 'childGridCreated'.

ASP.NET MVC

MVC offers some additional challenges such as the relevant Merge Unbound Columns property and others. First and foremost let me remind again the SetUnboundValues’s Dictionary method overload is still your best bet to get things going as expected. Also the client-side explanations above still holds true although this time you set values to column layouts of the main grid, but it has to be done for the respective layout.

Using the Unbound values column property which if used in child layout definition will be applied to all layouts by default. However when you enable merging the values inside the column definition are not supported and pretty much ignored. So in their place you get the default null values and empty columns on the client.

Then you have the SetUnboundValues’s List overload that suspiciously looks very much like the property, but you will be surprised when it actually works with merging. But there’s also a catch – since the method’s purpose is to provide all values for for a grid in one go, when used it will still map values to ID’s ..of the first child layout only. This is as far as the grid is willing to do the guessing for you I guess. However if the child layout doesn’t have primary key another default behavior kicks in and those values are applied separately to each child. I’m only explaining all of this as I think in some situations child layouts could be sharing values or just need an example values for one layout and these can turn out just fine.

Once again, assigning with the Dictionary overload applies the required mapping so values will properly be added throughout children  based on key matches.

Load On Demand and Merge Unbound columns don’t go well…

These really don’t go well at all! And it’s really not that surprising – LoadOnDemand assures the grid that data for child layouts will be provided later on and merging demands they are present in the data source, so even though you may have Unbound Values set using the property itself and you can see it on the client code it will still be ignored and data for the unbound columns will be required from the data received when creating the child. That mean that you need to send it along with the original grid model and this makes the Unbound Columns redundant or if the source is oData nearly absurd to implement. SO better don’t try this at home. The best part is that if you don’t provide those values and the grid starts looking for them it will end up badly..with exceptions :) This is true for SetUnboundValue methods as well, however this is not hopeless combination of functionality:

GetData() to the rescue

Of course, this is the Grid models’ GetData() method and it’s extremely helpful when using load on demand. In fact, so helpful, that when used to generate responses for the child layouts it will look at your model and properly merge unbound values applied with SetUnboundValue methods again following the default  behavior – with list values are added to each generated response essentially added to very layout and with dictionary overload just the matching ones. So this (lines 73/74 in the model show the setting of values with both List and Dictionary):

Will produce the following response to the client:

Even when merging is not in use, this method will be kind enough to include the said values as metadata instead and achieve the same results. One thing to note is that the method does require the presence of primary and foreign key in the child layout in order to perform proper mapping, which if not needed can be hidden but still must be present. Despite that,  using the Grid model with Load On demand is the best way to have child data generated properly and it allows Unbound Columns to be merged along with all else!

Bonus scene (formula + template)

Or more like bonus scenario. Since unbound columns are not even tied with values what happens if as above and examples before you got that Unbound Column with both formula to calculate total and template. Now that template uses a static value for the max…how about we add yet another column for that, provide some values and use that instead in the template?

Would it work as expected? For a moment, it might. See there’s no merging enabled, therefore it happens on the client and since the schema doesn't include the Unbound columns the grid isn’t as kind as to go about and apply null-s to every record missing unbound value. So in essence unless you provide all of them, records will not even have a ‘max’ property and guess what happens when the templating engine tries to get a value for it :) But no worries, a solution is possible using yet another formula:

And in it you can assign values or in this case keep the ones available and place defaults. It doesn’t even have to be null-s anymore:

And you get quite lovely results:

Resources and demos

• How to get started with jQuery Grid Unbound Columns

  • Why Unbound columns?

  • Quick setup + with ASP.NET MVC wrapper

  • Adding data: with the UnboundValues property, Set Unbound Values methods and calculating them via formula.

• How to configure jQuery Grid Unbound Column and make the most of it
  • Merge Unbound Columns property and Performance implications
  • Merging Unbound Columns and setting values on data-bound client event
  • Client-side methods to get Unbound columns and their values
  • Using unbound columns with advanced column options such as Templating or formatting.

• You can instantly try the the feature with the following JSFiddle-s:
• Updating and setting unbound values. Transactions.
• Setting unbound values in both parent and child layouts in the Hierarchical Grid
• I’ve prepared a fairly elaborate ASP.NET MVC project with various grid configurations described above with both jQuery/JavaScript and MVC Helper. Keep in mind most views use the MVC wrapper and require at least a trial version of Ignite UI on your machine – click the banner below to get yourself one.
• There are two demos available in our Samples: Unbound Column in the Grid and Unbound Column in the Hierarchical Grid.
• You can find general and control specific help in our Online Documentation
• You can find the client-side options and methods in the Ignite UI jQuery Grid API reference.

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

TL;DR | Summary

In this article we covered the usage the Updating feature with Unbound Columns in the IgniteUI Grid – how to deserialize the now non-conforming model of data the client side jQuery widget is sending. We also looked into the proper methods of setting values so they can be persisted and how to deal with editing and formula updating upon dependency field change.

In addition to those, some light was shone upon how the Hierarchical version of the grid ever so slightly differs from the flat one and the unique challenges it poses – setting values and the dynamic creation of child widgets. The odd interaction between options such as Merge Unbound columns and Load on Demand and just how bad can things so and how useful the ASP.NET MVC Grid model ‘GetData()’ method can be to prevent that. Lastly, a small demo just to give head up when using Unbound Column values in templates without merging values on the server.

Not so long ago when Jason announced IgniteUI and a plethora of other goodness he mentioned a tool called Configurator that would help you code (or not code really) widgets included in the suite. As as he put it, for all of you server-side developers with desire to fire up your pages with some HTML5 and jQuery that sounds fantastic!

“Configurator for IgniteUI jQuery widgets?  Where?  Why is it not in my install folder/IDE?”

So yeah, there’s that. It’s not something you’d find in the installation of IgniteUI. It’s a live tool actually and there’s actually a link for that in the post in case you missed it.

You could always follow the direct link to the Configurator which is http://labs.infragistics.com/jquery/configure/, but it’s not all too confortable and far from enough don’t you think? Well we agree and we are moving forward with the Configurator making it easily accessible from the IgniteUI home page:

There you go, now you know where you can find it when you feel like some fiddling.

Note: This is in a early stage (hence the big ‘BETA’ stamp on it). While we welcome you to give it a try, you shouldn’t expect correct behavior in all cases.

The Goal

Speaking of  fiddling the experience does remind me a bit of a reverse JFiddle – where you start from the results you want to see and get the code as a result. And that’s exactly what this tool is all about - it’s all “Developers, developers, developers!” deal with this one. And if you are like me and you love to learn by example and in our line of work that is by code. Then getting a ‘default settings’ code with very little knowledge of the IgniteUI controls – sure we want that. Also improve the learning curve of the controls? Why yes please! Experienced developers could instead use it instead to grab a quick piece of code to begin molding to their needs? Sure! There are a whole bunch of ideas behind such a tool that are just awesome. And you can say that yes we have samples (which I might add are quite awesome!) but they can’t cover all the events a control has as it would just not make sense in a real case. Also there are sometimes more properties that can be stuffed in there as well. And yes we do have rich API reference that lists all options and events, but hey what if you could see what they do instantly? What if the demo-ing control could also be modeled to your specification and data model? Well that’s the goal! To let you access and customize controls in a familiar fashion and with boosted speed and ease.

The Configuration ‘studio’

It’s kind of weird to have a getting started guide for a tool that is partly here to help with get star.. you get the point! Well ‘Introduction’ then. Firstly, you don’t really need to worry about resources and stuff, just follow the link and tweak/fiddle! Once there you will see the ‘studio’ has three main areas – toolbox with IgniteUI controls, live workspace and Visual Studio style properties and events tabs ( nice touch with familiar experience there):

Furthermore, on the matter of properties – the configurator is aware what are the default options for the controls so when met they will be omitted to produce clearer code. Let me give an example – as with the editor above you can set the vote count to 6 or 7 and that will reflect in the code, however when you enter back 5 the property won’t be in the source anymore as that is the default option to begin with. And once you are happy with the result you can hit “Source” and grab the corresponding code:

Note: While the code field is editable as I said this is like a reverse fiddle – the source is generated from the design rather than the other way around and changes made in code will just be lost once you switch to design. This is somewhat of a limitation regarding events as you can see – you get a handler function prepared for you, but since the tool can’t anticipate what it should do it is empty.

So we heard you like Grids…

So while the Configurator has a lot of catching up to do, but there has been a special focus on our powerful and feature rich jQuery Grids! And by feature rich in this case read “a plethora of settings to customize each” – I don’t even know if there is a golden middle between ease of use and freedom for the developer, I guess IgniteUI grid features being separate widgets helps some, but it does sometimes make it hard to find what you are looking for. For that reason the grids are sometimes difficult to configure and this is where this tool shines. Currently it does have some quirks still so I’ll attempt to guide you. Once you have picked a control you get it in a ‘sample’ version with some dummy data..that unfortunately isn’t being pre-populated in the options to the side. So if you want to get some customizations rolling, first make sure you have your data set. Simple walkthrough with a grid:

• Start by setting the data source type and response key (if any, as with lack of scheme it is used to parse the data) before you paste actual data because for now the workspace is not equipped with a reset button and the grid will error out attempting to parse the data:

Also for advanced features it’s best to also set the primary key. After that you can paste your data in the data source field. Here’s mine and you can reuse or just provide your own:

The grid is auto-generating columns  by default and once the source field loses focus the grid should appear.

• Tweak options. Keep in mind field blurs cause the demo grid to reload with the new settings and produce errors if vital ones are missing/incorrect. Also enable and configure grid features! In the properties tab there’s a features option with an edit button that takes you to a view with all available features that can be enabled:

And as you can see each feature has its own ‘Edit’ button that takes you the respective feature widget options where you can toggle and set even more options and at any point you can hit the source and grab the generated code.

Note: What I explained for the grid with dummy data and the need to provide your own is true for all data bound controls at the moment. So, for example, a Pie Chart would require you to set data type, along with Value and Label member paths and paste something like the following JSON:

[{"Budget":60,"Label":"Administration"},{"Budget":40,"Label":"Sales"},{"Budget":60,"Label":"Finance"}]

This is the actual pie chart dummy data by the way :)

Just for now

For those experienced with web development the developer tools console of your favorite browser should feel like natural habitat. For those not so much experienced, well lets say that is while you are making changes something goes wrong for now the way to get at least some in for is by looking at the console. Also while at it you can use it to define global variables and functions to use with the controls – there are no iframe-s going on in the Configurator so you won’t to worry if those will be available.

Looking ahead

It seems this is quite often the case – the simpler a tool is supposed to make your like, the harder it would be for someone else to create it. It’s really a lot of work to make this perform flawlessly and then even more so to pack it up with amazing features. So as I mentioned before it is in beta stage and right now is the ideal moment for your voice to be heard.

For the future of the tool we’d like to let you add multiple controls to the workspace and also provide generation for ASP.NET MVC code. There are also a number of functionality enhancements and fixes and until then if you get stuck.. refresh away :)

We would appreciate feedback on what you think about the tool, what would like to see in the future and how would you like to use such a tool.

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

Out of the new and exciting things happening around IgniteUI is the enhancement of the mobile toolset. These controls are based on jQuery Mobile rather than jQuery UI, as it provides optimizations for mobile devices. Applications built using them meet the demands of phones and tablets when it comes to usability and design. Windows (Phone) 8,  iOS and Android devices are everywhere and the flavor of the year word is TOUCH  - support for that and responsive design both come out-of-the-box. But this isn’t the first time we’re taking on the subject – some time ago (in 12.1) we released the mobile ListView and Rating where some parts were covered. Even though for now I’ll keep to the present and show you some of the new stuff, leave a comment if you have some thoughts on anything else. Also make sure to check out the topmost link for a list of all IgniteUI changes.

So, possibly the biggest change introduced with 12.2 now is for all of you ASP.NET MVC lovers :) We’ve devoted effort to enrich the mobile toolset by adding 17 ‘new’ controls by providing what we call “re-assurance” wrappers around existing jQuery Mobile controls. What this means is that you get not only Infragistics support for them, but hey, as part of our suite you can bet on each of them having a model for neat ASP.NET MVC Helper action! Yup – means you can code jQuery Mobile based applications with Razor syntax in C# or VB.NET! Also you get enhancements such as the control model themselves so they can be configured outside the View as well for maximum control and when in the View – the option to create strongly-typed controls!

What are the goodies?

With the latest additions the IgniteUI package is capable of delivering an application in its entirety all in the comfort of the IDE and language you feel accustomed with. But it’s not just the controls that grew in numbers – to truly provide a full-fledged end-user experiences we also added themes for Android (whole 3 of them) and two for Windows Phone! And there’s even support for adaptive theming to match the device platform feel! I’ll try to demonstrate different themes along the way and you can always hit up our samples and see for yourself!

There are also a number of benefits you get – the mobile jQuery controls now have their own section in the IgniteUI Documentation/Online Help with very useful mobile-centric Deployment guide and detailed control documentation. You should totally check that one out as well.

In addition to what I mentioned above ( the comfort of your IDE and language, strongly-typed) the MVC wrappers bring quite a bit more – having server model of your client controls lets you define them without requiring the knowledge of their HTML structure and with IntelliSense support.

They will also prefill defaults for you, the ones that matter the most – required for the control to be initialized,  automatic element IDs and in the case of strongly-typed controls like above the proper model property will be set as both ‘id’ and ‘name’ attribute of the elements in order to be properly picked up and sent upon form submits.

In case you think typed models of controls will take away the freedom you can have with just HTML, you can rest assured that is not the case as all the models accept extra settings via the HtmlAttributes method.

Getting started with mobile controls

Let’s see just how easy it is to create basic mobile applications. Make sure you have followed the Deployment guide above and referenced the jQuery mobile recourses  and IgniteUI ones or the mobile version of the loader widget.

The most basic control you could use is the TextBox that supports different modes such as password, multiline and search.

And this in the Android “Holo Light-Dark” theme comes out as:

Then you can have Buttons of course! Notable properties of the buttons are the icons (with related positioning properties) along with the ability to define them as inline (otherwise to ensure fit for small screens jQuery Mobile elements are usually displayed in block, as in a new line):

I’ve also added the style in here so you can see that you can even make use of the html attributes to add class and apply custom styling:

That doesn’t really fit, but oh well :)

Next up is the Slider so let’s see how you can set it up on the server using the model:

You can pass the model itself if you will, but I’m actually using the dynamic ViewBag because I have more then one model for that view. The Helper as always comes with an overload taking a ready control model:

Moving on with the all-time favorite Toggle switch. It’s one of those mobile specific controls that is very easily recognized. The two states of the control are called on and off and you can specify text for both, as well as initial state. With all controls you can also apply themes (or swatches as they are defined within the jQuery Mobile styling):

Those are the Android-styled toggles.

Another very mobile-oriented control would be the Select Menu– very much behaving like a select but with enhanced popup-like modal selection for better mobile experience. Much like other selects and combo boxes, it supports both single and multiple selection, the option to use native menus ( don’t know why would you punish users like that, but it’s there) and a collection of items:

The interesting part is that it would also display a counter if multiple are selected(if you want it to naturally – as with most it is customizable):

Speaking of selection there are two more well-known user-selection that the above menu is really based on. First are the Checkbox and Checkbox Group– fairly simple two-state input element, that when used in group allows for multiple selection. The checkbox can be used as stand-alone as expected or as part of the group model’s collection of items:

And if you set the ‘Horizontal’ property to true you get a single line button or also called toggle set:

The other selection option in the toolset is the Radio Button Group– with the difference that radio buttons make no sense outside of a group and when grouped only a single one can be selected. Again as you’ve seen above you can set initial selection, but the group model itself can be assigned a ‘SelectionIndex’ (but keep in mind it is overridden by selection assigned on the radio elements themselves). Also, much like above the the group can be set up as horizontal button set:

As form elements

Since in this article the main focus is on input elements, I feel it’s important to explain a bit how they work in the context of HTML forms. Usually you will be working with all familiar elements, however as mentioned above some controls provide the ability to use native ones – what does it mean? Well, even though there are probably default UI elements available, in jQuery mobile standard elements are primarily built out of spans. This ensures no browser enforces its own default UI or behavior and therefore cross-browser compatibility. This applies to things such as buttons, checkboxes, radio elements and so on. However, in the interest of remaining with a functional application when jQuery mobile is not supported (simple HTML mode, no JavaScript - although I have no idea where you'd find that except for those that turn it off on purpose), buttons (and other inputs) intended to perform the default browser submit functionality will be created as styled standard input of type submit.

Also a very important part is that the IgniteUI ASP.NET MVC wrappers will create the proper markup (such as intended to be used with jQuery mobile) that would create native browser elements and assign them the proper ‘id’ or ‘name’. Those contain the actual values and are the ones picked by the browser on submits. However, when jQuery mobile is functional they will remain hidden, while the user interacts with the enhanced mobile controls. That also means in case something goes wrong the application will have this whole set of active controls and will perform as expected, but with reduced usability. Again this is something you won’t have to worry about, but it’s good to know.

TL;DR | Summary

We’ve looked into mobile controls that assist with user input and help you create immersive mobile experiences that implement cross-browser and cross-platform responsive design and go beyond – while optimized for touch and mobile, jQuery mobile applications actually look and work beautifully on desktop browsers! There’s a very extensive list of supported platforms and let’s just say the A-grade list is impressive.

But there’s more – the IgniteUI mobile toolset will also provide you with a number of wrappers around layout elements to help you build your application that much easier in a familiar way and environment. So stay tuned for the upcoming blog demonstrating those, demos and more! In the meantime you can always try it for yourself:

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

After we’ve looked into the range of input jQuery mobile controls you can use with the greatest ease with Ignite UI ASP.NET MVC wrappers, there is something more you can do. If you try the snippets as is you will find them working well and in tone, but rather lacking in terms of layout. So now that you have an idea how to provide content, let’s wrap it up in some proper containers and provide navigation.

For the record, it’s only fair to say that if you run a sample with just the controls defined you still get the entire page styled. Why is that? Well you can have a look at jQuery Mobile’s “Anatomy of a page”. As it says there the layout consists of conventions, rather than requirements. Wheat this means is that you are not forced to add a header, footer, content or page for that matter. What jQuery Mobile will do is to wrap your entire HTML in the body in a DIV with the page role. That while convenient is not optimal – if you have script tags in the body the process of wrapping the content will also load them again, so it is best advised to still have a properly defined mobile ‘page’ in your HTML. This is also absolutely necessary when two or mode pages are to be delivered in a single file, and yes, that is possible, but again not recommended way of design. So yeah, conventions and not requirements, however those conventions are there for a good reason and you are better off following them. So how about Ignite UI ASP.NET MVC wrappers? Will they help here? Sure!

Mobile pages 101

Let’s start with the most basic thing – the actual page. The helpers will  offer a way of defining it that is very similar to how you would go about a Form element. That is in the sense that there are separate methods to begin a page and to end it. However, unlike the form being a set of two methods, the page being Ignite UI means it can also be initialized with a Page Model passed to the view. Here’s how a simple definition with chaining syntax goes ( logically, any options should be in the page opening) :

And as I mentioned this can be done via Page Model:

How about that back button setting up there? What could that possibly do? Well it’s related to the next otherwise not required layout element – the header. For that setting to have any meaning, you will need a header on your pages as the button will appear just there). There’s another button that you can set text (for tooltip) to but you can’t customize, and that is the close button. Page with close button? Of course, that one is present when the page is opened as a dialog. We’ll talk about how that goes later or, but keep in mind it only makes sense to set one as the close is dialogs’ replacement for the back button.

Headers are used in much the same way as pages (begin and end) and among other things can be set to fixed position:

The ‘FixedOptions’ can also set behaviors like tap (or click) to show/hide the fixed header and transition animation for showing (the default is slide). There’s more of course and you can pay our Ignite UI Mobile Documentation a visit. The And you will see something similar to this in the light WP theme:

Linking

One thing still is escaping – how did the user get here? Well he followed a link of course. jQuery mobile provides some enhancements to those as well. Links can be in three styling modes – the native for the browser, the link styling of the theme or as a button. Note that links inside headers and footers will always be styled as buttons whether you set them to or not. Also I mentioned dialog and you can tell the framework to load something as dialog when you specify an option on the link itself:

The above will produce:

As you can see you have the option to define a relation with the destination or the link, and this is how you create interactions to open up dialogs and popups. This is a similar page opened up by the dialog link above:

You can also specify relation to be ‘back’ so you can add back buttons not just in headers but anywhere in your content. Keep in mind automatic Back button on on pages only appears if there's actual history – as in when they have been navigated to by a link. This is somewhat important to know when using multiple pages in a single document (even thought it’s not a recommended practice) as you can force loading secondary pages by entering their URL but this way jQuery Mobile won’t add those to the history. Still, there’s a very minor chance someone will be entering links by hand, but you never know. Also for back buttons it’s good to still provide a meaningful link for browser compatibility.

More?

So far you can create basic pages and provide navigation. Also at your disposal is the content element – as the documentation describes it is helpful for “providing some basic formatting and structure”. But, hey, have you noticed the simulator screenshot in the previous blog? Does it seem odd items are stretched so far out it feels they are about to be cut off by the viewport edges? That’s because as direct page content they tend to spread to the maximum width… Wrapping those in a content element is at least the easiest way to provide proper formatting as the content will squeeze them a little. Also you can set separate theme to he content this way or apply classes to add custom styling and behavior with.

The same statement that describes the content is also true for the footer. But while it is not required for automatic page functionality like back/close buttons and it also serves the structural and potentially visual separation of content, it can much like the header be fixed, which can sometimes be really useful. So for that secondary page we have above we can add something like the following:

Enhanced Layout

Now that you can properly fill those pages comes yet another potential problem. While you have been refactoring your site’s experience into mobile pages to be properly consumed on mobile devices it still is too hard to fit relevant content together into a single page? Well you don’t have to, really.

You can separate content that is not for immediate consumption or instead of swapping pages on some event show content in a popup. It’s extremely useful for a range of cases – from simple tooltip to login forms and application menus. Keep in mind the popup is available from 1.2.0 version of jQuery Mobile! Like other content containers, the popup has begin and end methods and content between them is not displayed by default. To display a popup you can set up a link (on the same page) that navigates to the popup ID and has a relation of that type and inside you can add another link as close button:

The button class can be left and right and the contents of the popup can be any HTML. As seen options include positional settings like centering over the element that was clicked (origin) or the window. You can even pass a jQuery selector to position the popup over the matched element. And the tolerance sets up how much in the minimum spacing between the popup and the edge of the window. The MVC wrapper method has 3 overloads that let you put a single common value, just for top and left or for all sides. The transition has the usual jQuery animations available and another allows (or not) for jQuery Mobile to modify the page Url and add it to the history. This means you can let your users to close popups with the back button.

Another extremely useful layout trick is to organize things within collapsible container. They come in two varieties – a standalone  Collapsible and a Collapsible Set. While pretty self-explanatory the single version consists of a header and a content block that is either visible or collapsed. You have a number of options to control themes, header state icons and their position and more. For example the default icons are plus and minus, while we can use arrows instead:

The set version is essentially an accordion – only one out of a group of blocks can be expanded at a time and current collapses automatically when the user opens another. The model is pretty much identical – you have the set that is a container for single collapsibles and it even has the same general options (icons, themes) that you can apply for all child blocks:

A nicely packed navigation

Of course, it’s always nice when you can make the web page feel more like an application and provide nice buttons instead of links. It’s also nice if those are not spread all over the page, but rather grouped. Here is where the Navigation bar comes in play – it allows you provide up to 5 (after which it wraps them in multiline..) buttons with customizable themes, icons and exclusive selection (kinda like horizontal radio group but without the form input support). This toolbar is most common in headers or footers. The control itself has a collection of items, global icon positioning an theme options. Each item has Url and text as expected:

TL;DR | Summary

In this article we’ve looked into the basic ways to create structure in your mobile applications using the Ignite UI ASP.NET MVC wrappers/helpers. In addition, we saw how linking between pages can be done with different relations and styles. Furthermore, there were the mode advanced ways to enhance experience with your app by providing interactive content with popups and collapsible content. Lastly, a more neatly organized way to build your navigation in a toolbar that also provides a nice touch of ‘native’ feel to the mobile app.

Make sure you stop by the first part for some input jQuery mobile controls you can use with the greatest ease with Ignite UI ASP.NET MVC wrappers, check out our Ignite UI Mobile Documentation and visit our samples you can experience on your mobile device as well! I have packed all of the described examples in a very simple ASP.NET MVC solution for you to download and try and in order to run that you will need at least a Trial version of Ignite UI for the mobile assembly, but hey it’s free, grab one from here:

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

This year we had the pleasure of being part of the second “Innovations in Software Test Automation (ISTA 2012)” conference! This year with even more companies joining for knowledge sharing, additional workshop/hands-on track and a lot more participants. ISTA is gathering a healthy range of quality engineers, software test automation experts and developers to the common goal of sharing new technologies and best practices in the fields of automation. This conference provides for a greater exposure of the software test automation role, which makes it a good place for some to choose career path, gain new insight( or share some of their own! ) and generally gain a better  understanding of just how diverse problems can be met and solved in the field. Our Principal Architect, Angel Todorov, who’s been recently focused on our Ignite UI jQuery controls gave an awesome presentation on Automated Web UI Testing… on Steroids! More on that later. The goodness spreading doesn’t have to be only once a year, right? Right. So the conference is also issuing a quarterly newsletter (you can sign up here). One of our talented Quality Engineers, Borislav Traikov,  has been providing some food for thought via article for the conference newsletter.

The Future of Story Tests with Selenium and WebDrivers

Selenium has been a recurring mention when it comes to Web Test automation – either directly, or a subtle-yet-preferred base for a framework, it comes up one way or another. And frankly I think that’s a good thing, as major companies having interest in the project simply means better support and contribution to it. And I’m definitely not the only one – taken from Borislav’s article:

Performing automated tests on web applications can be crucial to the success of a project, due to the fact that cross-browser support is a mine field for potential problems and defects. On the other hand, web applications are platform-independent (for the most part). Thus, they can be tested natively (with frameworks such as QUnit) in the browser, or by frameworks that utilize first-class languages (such as C#, Java, Python and so on, while this choice provides a wide window for automated testers to step in and start writing tests. So, if a web application testing framework is to be successful, it should satisfy these needs. Selenium has been doing great so far, providing a cross-browser API over multiple languages. While the Selenium API provided great DOM abstraction and traversal, it had its shortcomings – the biggest of which was its use of JavaScript sandboxing (Selenium v.1, also known as Selenium RemoteControl, used the JavaScript engine of the current browser as a way of interacting with it). In most cases that wouldn’t matter, but with more complicated web applications under test, interaction with JavaScript events, rather than emulation of real mouse clicks or keyboard interaction simply wasn’t enough. Also, the Selenium API was growing steadily with each release, and while that was awesome (grey areas were addressed and bug fixes were applied), one had to wait for a release or two to get the API method that they sorely needed (or extend the framework themselves – after all, Selenium is an open-source framework).

While Selenium was rising to fame among automated testers and gathering commercial support, an engineer at Google wanted something more: a test framework that would break free from the JS sandboxing and instead would natively speak to the browser. With so many different browsers, that was no small feat. Thus, the WebDriver project was born. With backing from Google, this automatically meant that Google Chrome (well-known for its distribution of stable nightly builds) and its little brother: the Android browser would be supported. This alone would open the door to a huge improvement in test automation, seeing as how the Android browser holds a solid 24% of the mobile OS market (during the time of writing of this article). However, the other runners-up in this “mobile browser war” – Safari and Opera – are still tough challenges for any cross-browser testing framework.

In 2008, the Selenium and WebDriver teams decided that it was time to join forces and to improve Selenium with the advantages of WebDriver: Selenium WebDriver. The transition from RemoteControl to WebDriver is still going strong alongside the continuous development of the WebDriver API – these facts raise both hopes and questions about the near and far future of test automation with Selenium.

There’s a ton of interesting info in there, pros and cons of the WebDriver and some thoughts on the (hopefully) bright future of test automation. It’s definitely worth checking out, so go ahead and read The Future of Story Tests with Selenium and WebDrivers!

Honorable mentions

That’s not all! There are more topics to spark your interest:

Software Localization … more than just using Google Translate, by Desislava Nikolova

Best Practices: How To Test Performance Of A New Product, by Grigor Svetoslavov

Automated Web UI Testing on Steroids:

Behavior-Driven Development, Headless Browser Environments, and Test Bed Generation.

As I mentioned Angel Todorov presented some of the methods and innovations used right here at Infragistics. Yup, it’s basically info straight from source and it’s pretty interesting stuff as well. The presentation covers a number of limitations, problems and approaches to address them. It starts by giving an overview of some common frameworks and practices used to automate Web UIs, and lists their advantages and disadvantages. It continues by describing a unified framework for UI automation, involving a combination of tools, some of which come from relatively new concepts such as headless browser environments. The key goals? -  Faster test execution, more reliable test results, improving code reuse, and achieving greater productivity!

There are details on the cucumber-based framework we are using to describe scenarios and features in the Gherkin syntax and the tools to integrate that into the process. It’s a style that provides readability for the test cases so the stakeholders and managers can take part of the action. Again, something you should definitely not miss – you can follow the link above to read some more and there’s a downloadable version of the presentation deck. For those of you that can’t wait here’s a direct link to slides for the Automated Web UI Testing on Steroids presentation.

I’ll end this with something I’d like to say, but as you see I’ll have to just repeat:

@ISTA_Conference

That was ISTA 2012! You guys rock, thank you! pic.twitter.com/JGnqlToy

And see you next year!

With the latest release the Ignite UI Tree has received the nifty feature of drag and drop. It’s a fairly common concept and it allows for a natural (at least I perceive it to be for a long time) interaction with the control’s items. From a user’s stand point it’s all but awesome news  - this would allow for nodes to be moved between one tree’s structure and in our case there’s a bonus of being able to do that between two trees even. The feature provides rich interactions with a familiar visual touch out-of-the box.

From a developer’s view things are also quite pleasing – the jQuery Tree Drag and Drop already handles a decent range of common case scenarios, so you can almost set one property and umm.. profit! Then again, when you do need to set things up it offers a possibly familiar API as you’ll see and has pretty much everything conveniently exposed. And while the widget itself will perform a solid range of drop validations it offers you the option to define your additional custom function.

Quick Setup

As advertised, this can be achieved via a single property and you can then kick back and enjoy the result with the defaults. Drag&Drop is build directly into the tree, so no additional files required and main star is the ‘dragAndDrop’ property:

This setup will pretty much produce a fully functional tree with the bare minimum of setup and the equivalent ASP.NET MVC helper definition is about as simple:

The resulting tree is the one you see in the heading image. Yes, the helpful indicator to the side too! Make sure you stop by the documentation and check out the Enabling Drag-and-Drop section where you can discover that there’s an additional ‘allowDrop’ setting that allows for nodes to be dropped in you igTree from another igTree!

Customizations

Now we come to the part that may be familiar to some of you – the Ignite UI Tree also accepts a ‘Drag and Drop Settings’ object with various settings for the behavior of the feature. Now a small deviation  - the reason why the settings might be not so hard to understand is because the control internally implements interactions from jQuery UI– the Draggabe (“Allow elements to be moved using the mouse.”) and Droppable (“Create targets for draggable elements.”) widgets. Taking a look at the descriptions for those you can tell why – just like the concepts of Drag and drop go together, so do those widgets and the tree  initializes both itself. Oh and that settings object? Yeah, some settings go almost directly to the Draggabe Widget’s options:

• helper – Defines what element (helper) should be used to for dragging display. More on that in the future, lets say you can use the original node or a clone too, just don’t deep clone :) Plus the helper I think will almost always end up being the better UX.
• dragOpacity( equivalent to ‘opacity’) – Opacity for the helper while being dragged.
• zIndex – This directly corresponds to the CSS z-index Property that will be applied to the dragged element. It specifies the stacking order of elements – making the ones with higher index come on top of those with lower. The default 10 is usually enough, but if for some reason you are having issues with your dragged helper being overlapped by something this is the property to increase.
• revert – this one is mildly different as for the Tree it’s a Boolean while the jQuery UI Draggable takes both boolean and two string options. The reasoning behind this is that in the context of drag and drop within the jQuery tree not all of those make sense – like reverting on ‘valid’ drops or always reverting. Plus it makes the option much simpler – false stays the same, while true defaults to ‘invalid’ instead.
• revertDuration - The duration of the revert animation, in milliseconds. Ignored if the revert option is false.
• dragStartDelay ( equivalent to ‘delay’) - Time in milliseconds after ‘mousedown’ until dragging should start. This option can be used to prevent unwanted drags when clicking on an element. This one is big on user experience I think – trust me when I say you don’t want this too low with complex control with elements that perform additional functions. Based on that the minimum you want is at least 100 milliseconds or you risk drags starting on simple selection and node expansion. It’s pointless overhead and even potentially successful but unintended buy the user moving of nodes.
• containment - Constrains dragging to within the bounds of the specified element or region. This one is quite versatile – taking a range of values like a selector, the actual element to contain within, string enumeration or even an array of values defining a bounding box. The default false setting restricts the drag to the parent element of the tree.

Possibly half of the others are left to the default and some the Tree widget reserves for itself. There are of course ways to ‘hack’ into those, but let’s not do that.. at least not just yet. But hey, here’s one that barely counts as one – the cursorAt that defines where the helper markup should appear relative to the mouse cursor regardless of what the name may imply is also defined, however it’s value is set form a constant within the tree and that can be replaced. Keep in mind there’s probably a good reason for that not be exposed, so use with caution – there’s at least one danger  - if you go too far and bring the helper under the mouse (which you might decide to do) I guess the validation of the drop target fails and all you’ll be seeing is invalid visual – you need the mouse at least 1px clear from the helper sadly. But hey, you can at least reposition the helper closer and to the bottom right corner (Explorer style) for example:

I’ll admit I didn’t do a particularly good job with that, but hey it’s good to know you can tweak that. If you have been playing with the feature so far you’ll also notice the invalid message is different (it usually  shows the name of the node you are dragging) – that’s because you can provide markup for any of the multiple helper states. You can look those up in the Drag-and-Drop Property API Reference where you’ll see the defaults too. Oh right, the code:

Regarding the various markups – you’ll notice they all contain an empty span. What’s up with that? Well, the span is the one being targeted by the widget to apply classes for the icons. If you want the icon it’s good to include a span in your markup. You can remove it to remove the icon, or leave just the span (with unbreakable space in the paragraph for height) to have a helper with icon only.

Notable mentions from the snippet above also include the mode of the feature ( move and copy available, the default option combines both with a ‘Ctrl’ as modifier. The line at 17 (containment: "#tree") prevents the dragging to go on beyond the boundaries of the tree itself (as in my case with a very simple layout the tree’s parent is the body and that doesn’t always produce good results).

Enhanced Events

The Tree will fire a number of events during the drag and drop interaction. The familiar equivalents of jQuery UI Draggable (start –> drag –> stop) are as follows: ‘dragStart’ –> ‘drag’ –> ‘dragStop’. A slight name change really to better suit the context of a more complex widget. Speaking of which, the control as you can imagine internally handles the original Draggable events to do its work and conveniently fires event for you to handle in the meantime, but that’s not the whole story. While, yes, the Tree will pass you the original Event object, the arguments you get alongside will be extended with a bunch of useful properties containing the path of the node in question, the actual element itself, its data record and appropriate binding. Again you can refer to the API reference or Documentation to get additional info on those. All are cancelable.

Since the Ignite UI Tree also must be the target of the drop, it also has an initialized Droppable widget. However, the events for that are different – the tree will fire events as the node is being dropped and after it has been dropped. As you can imagine the first one can be canceled and is a good place for last checks to see if the node dropping is in an acceptable position. These come from the single ‘drop’ event of the jQuery UI widget, so what happens with the rest? Well, they didn’t make much sense for the Tree, but if you really need to handle some of them for any reason don’t despair – unlike the draggable deeper inside the structure of the control, the Droppable is initialized of the very same element as the igTree and you can handle it’s events just as described in it’s API, for example:

Also you can handle the ‘drop’ as well, but keep in mind you won’t get the extra info the Tree provides in the delegated events and when you do handle drop your handler is likely to be triggered before the Tree’s so you can’t really verify the job is being done there. Just, whatever you do, don’t handle those with alert like I did! :)

Limitations and not so much

I mentioned the control will do a plentiful amount of validation (even without a custom function) in order to maintain reasonable behavior (like the droppable not accepting anything you throw at it an such). The tree will also validate the drop target is an acceptable part of an igTree widget’s UI. in addition to that, as I mentioned before, there is also a binding validation. What this means is that the node being dropped on must have bindings compatible with the dragged node. Take the case above – we have a top tier of Categories whose children are products. Based on that the control will not allow you to drop one Category into another (as the accepted child is defined as Product already). Same goes with trying to drop product in the root (where category is expected). If your models allows identical bindings on all levels then you can ignore that.

This leads to some issues with performing Drag & Drop between two trees as well – you can’t simple define two completely unrelated trees and expect to be able to move nodes between them. Again similar bindings should exist in the trees in order for the move or copy to be accepted. I’m not sure if it’s a limitation if it’s reasonable, but hey you can always work some magic to get around it.

Resources

First let me again remind of the elaborate Ignite UI Tree Documentation and jQuery API Reference. Then don’t forget the awesome samples:

• Drag and Drop within a single Tree– you can observe here two interesting behaviors of the control – when checkboxes are enables their state will not be preserved when moving, however when dropped on a parent whose tri-state box is fully checked (meaning every child also is) then the newly added node will follow that rule and also render with ticked checkbox. Also dragging a node over unexpanded one will (after a short timeout) expand the drop target.

• Drag and Drop with two Trees–  moving nodes between controls with identical binding while avoiding dropping nodes on the ones marked as a file via a custom validation function.

• Simple File Manager– Using Drag & Drop to organize files and folders and an additional droppable target you can drop nodes to delete them – all while watching the respective events fly in the log.

Stay tuned!  There are some more neat tricks to share about this feature and I plan on another part along with demos!

Summary

We can all agree that Drag and Drop is awesome, simple and intuitive and it’s always great to be able to provide that for your users. As we’ve seen that is as easy as child's play with a mere property or two. However, once you know what you want and the defaults are not it – there’s a plethora of knobs to tweak and some of them.. do they sound familiar? Yes they do, as some come directly from the jQuery UI Dragable and Droppable widgets. Helpers are separated for cases so each can be controlled separately. The control handles much of the work for you by validating proper drop targets on multiple criteria while still providing you with the option to build on that – be it with validation function or by hooking up to one of the elaborate events. Go check out those samples and stay tuned for more!

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

As promised in the previous blog on Drag & Drop with the Ignite UI Tree– some tips and tricks coming right up. If you haven’t already looked into the control’s features, now’s your chance – overview with main ones listed in the Documentation and live in the Samples. Looking at those, while each of them is rather nice, how do you think some of them would work alongside each other…and is something missing? The first one is always a potential trouble maker and the latter.. well extending functionality is fun, but as you know there are always new stuff coming with each release – might be just the thing you are missing. We do take feedback on everything through socials (links always below), there’s an active community at the Forums and you can always submit a feature request( must be logged in). Enough with the shameless plugs, on to the discussion!

Play nice?

As you’ve already seen in my previous post there are some quirks for example when you have nodes moving around with Drag and Drop and checkboxes at the same time you will loose the checkbox state and when a tri-state parent is fully checked a dropped node will respect the valid-for-all rule.

It’s merely the fact that while drag and drop is a nice interaction from a user standpoint, underneath it involves removing and adding nodes. While that is simple in itself, it does present a number of situations where it can be really tricky to preserve whatever state the node may have applied by multiple other features. There’s a similar scenario with selection when you move the selected node around – you still keep the selection data, but the visual is gone as the node is re-created.

Then you have another major feature of the Ignite UI Tree – the Load On Demand. This is an extra tricky one actually. While the moving of nodes happens entirely on the client and there’s little that can come in it’s way.. it’s really hard to add a node to a parent one that hasn’t yet populated its children. Yes, you can easily supply the UI, but the underlying data source would still contain no array of child items for you to add to. Of course, one the node populates it’s all good and cool, but as you get told everywhere users are notoriously impatient and in case they do not wait for the node to load it can get quite messy.

Do keep in mind thought, the Ignite UI toolset keeps evolving with not only new features, but general improvements as well and it’s certain Drag&Drop will become more in tune with the rest. For that reason, what I do provide for now would possible become obsolete, but it’s more of a testimony  to the fact that you can enhance and extend Ignite UI controls with very little effort!

Play nice.. or I’ll make you!

So let’s get on with the modifications. The Tree’s events will be our heroes of the day as many if not all major changes are represented with them. I have one very easy fix for maintaining proper selection UI with truly minor effort – as I said it’s all really a matter of picking the right time to hook your code. I figured it’s mildly pointless to update a second selection variable on each change, so instead I will check when a drag is starting if the node in question is selected. Then when the said node is dropped I would simply use the API method provided for selection. This will in essence go and set in the new path for the node:

The difference from what you have seen before as code for the tree are the dragStart and nodeDropped events. Because those come in line of the jQuery UI Draggable & Droppable events and they can generally handle interaction between two trees, you won’t see the familiar ‘ui.owner‘ to access the tree as it’s kind of hard to tell which tree should be an owner really :) However, since I’m adding handlers separately that’s okay – I know which tree to call. Also, the tree is helpful enough to give nodes by paths – the latter you can get by combining the event provided path (the parent one) and the ID of the dropped element. The way this handles it right now should be suitable for deeper hierarchy that two as well.

Note: Remember you have the same event arguments as in jQuery UI in addition to the Tree adding some stuff (the element for example), but in the case of the drop the element is the actual target and the draggable from the original arguments is the node being dropped. The results:

You can take a very similar approach with the checkboxes in bi-state mode Trees to complement that feature, however, the tri-state limitation I feel might be the right design (respecting the parent global state). Up to you really, the option is there.

Load on Demand

As I mentioned it’s nothing that complicated stopping this from being flawless, except the very nature of loading data on demand..it’s not there yet! And if the user doesn’t want to wait things go bad. One very simple way is to decrease the expand delay (time till nodes automatically expand when dragged over) to mere nothing. This might make it work just fine if the service you use is fast enough to get ahead of the unsuspecting user. However, go too low and you risk the user triggering a whole bunch of requests on the drag path and actually making the application slower rather than faster. The solution lies in not letting the user drop on non-populated node. However, that would mean that at some point the node would expand and drop would be possible, but the helper will still be showing invalid location. It’s not such a nice experience to make the user shake the node around to force a drag and re-evaluation of the drop target. If you want just the perfect experience, you can have it with one trick – move the mouse for the user! Yup, basically listen for when the node is populated, check if the user is on top of it, and trigger a mouse move so the validation will be re-done:

As you can see the Tree is bound to the oData Northwind service making calls only when needed, we listen for populated nodes and save them in the ‘stateHelper’ to later trigger the mouse move on them when the UI has been rendered.

A word on the custom validation function

The thing about this functions is that it will be overridden by the internal tree validation, which makes it the last last chance for you as a developer to return false and prevent a node drop on that target. What this also should tell you is that the internal validation will try to validate actual Ignite UI Tree as a target, so your function is not to enable something the feature won’t allow – no call will be made to it when the target is foreign. This begs the question, can you still use other targets? Yes, the drop events still fire on the drop targets! Take the Simple File Manager as an example – the trick is in the usage of the droppable events instead!

And as you have already seen form above the context of the function is the droppable element and the parameter is the draggable.

Last but not least, if you are wondering how this JavaScript function is being used with the ASP.NET MVC wrappers, the MVC side property accepts a string with the function’s name. What that means is that such functions need to be discoverable on the global scope (on window really), so be careful where you define it:

And then:

1. <script>
2.     function customValidation(element) {
3.         // omitted
4.     }
5. </script>

Resources

First let me again remind of the elaborate Ignite UI Tree Documentation and jQuery API Reference. Then don’t forget the awesome samples!

This time I’ll add in the mix a solid ASP.NET MVC demo project ( with everything from here included in with both MVC helper and script-only demos, plus some basic stuff from the previous post). Make sure to check that one out, the animations above don’t do it justice!  You would need at least a trial version of Ignite UI so hit the banner below if you are still lacking one.

Also you can go for fiddling with two demos on JSFiddle:

• Basic settings and events + enhanced selection demo
• Modified Drag&Drop + Load On Demand behavior with Custom drop validation function.

Stay tuned, for there is still more awesome tricks I have for you – next time we’ll do some updating support!

Summary

This was the second part of the in-depth look at the Ignite UI Tree’s Drag and Drop feature. We covered some of the challenges such functionality presents and how you can overcome them. We improved the selection handling of moved nodes, we made the experience a true joy with Load on Demand. We also gave a little attention to the custom validation function – what is it for, what to expect and what you can do with it. At the end of this, I would like to remind you that this has been a proof of the concept that the controls are flexible enough to let you mold them to your needs with little code and great impact!

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

As it turns out the Drag & Drop feature is like the gift that keeps on giving – new year and new enhancement to the functionality! May be because the Ignite UI Tree is flexible enough or maybe because the functionality itself is based on simple Add and Remove API coupled with jQuery UI interactions, both of which are easy to understand, manipulate and extend :)

I’m thinking once you allow a user to move nodes around at one point you might come to the conclusion that some of those changes can be persisted. And as with most user actions - no surprise here! -   mistakes do and will happen. That gets us to yet another point – why not add functionality for the user to undo and redo Drag & Drop operations? Indeed, why not!

And while it does require some custom code, as we are trying to make this interaction feature into an editing one, which is not how it is intended in its current implementation. On the other hand, the custom code is heavily reduced as we have a number of building blocks right there at our disposal. So far we’ve been looking into the usability side in the previous post with Tips on Drag & Drop with the Ignite UI Tree and some basics of the Drag & Drop with the Ignite UI Tree– make sure you check those out as we’ll be building on top of some of the knowledge gained and this time dive into the functionality. I’m not saying the enhanced selection and Load On Demand were not functional, they were, but if you look at it this way – they were tweaks based on the Draggable and Droppable nature implemented by the control. Now remember the other API part? That’s our target now..

Leaving a trace behind

I’ll try not to bore you too much with Add/Remove ‘getting-started’ stuff, as someone else was kind enough to do that – check out the Adding and Removing Nodes Help topic and there are some online samples for those API methods too! The thing that matters the most to us is that those operations create transactions in the underlying data source log and that Drag & Drop uses them. Essentially, we already have a history of the node moves, all you have to do is send it and provide server-side logic to handle the changes. The only thing to keep in mind is that a drop actually calls both methods – removing the original node and adding it to it’s new place. That in turn equals two transactions per drop, rather than one.

The tree also provides an update URL property to set to an endpoint to send transactions to (I’ll use the a similar Tree as the last two blogs for simplicity, again with Northwind’s Categories) :

Note line 11 where we set the action link. And, of course, this can be in client-only script as well:

The controller action will have to deserialize the transactions and make sense of them. You have to do the same too I think, here a quick anatomy of a Tree transaction:

• type – either "addnode" or "removenode" based on the method used. Remember you get both per single drop!
• tid – generated ID of the transaction, useful for deleting a specific transaction.
• tdata – all the important goodies are here : the ‘path’ of the node on which the method was performed and its entire ‘data’ record. It also contains a ‘parentPath’ for add operations.

As you can tell from the path we can assert from where the node was removed or to which parent was it added. Don’t forget to validate! That is the reason of the custom function, the Drag & Drop would usually allow much more that it might make sense to your model, especially so if you slack on the binding definitions. The function in this example denies a node from being dropped on it’s current parent or one of the other nodes with the same depth as they are all products. Saving  the changes should generally be as simple as calling a method, however in this case, since the Add Node API method accepts multiple nodes (unlike the remove that is by path which is pretty specific), its path is an array instead of simple string. In a Drag & Drop scenario the add method will only be called with one value so you can go through the changes and normalize the path of the transaction (Drag & Drop would not add multiples) and unify them:

Here’s how the controller action looks like:

As you can see I’ve pretty much made this for the Drag& Drop only (thus the validation if it divides by 2). If you use this in addition to programmatic calls to the Add/Remove API this will require more work ..or the result will be unpredictable. I’m also validating that each two are an add and remove combo and if the path is identical it means this is merely a change in order. Once that is done the actual business part is getting the Category ID (which is the parent part of the path when you have primary keys defined) and assign the one from the add operation to the product.

Go there! No, come back! Actually…

Undo that and redo this. It’s those ‘phew’ moments that always make me happy when I realize I haven’t forever lost something. This part however can be either pretty simple ..or somewhat harder to implement than updating depending if you care for nodes being dragged and dropped around under their parent – as in if you care for order. The reason for this is that the paths for nodes generated by the control instead indexes normally, will actually consist of the primary keys if you have some. However, primary keys will only reflect the node’s place in hierarchy but not the order. Since the igTree I’ve been using so far has primary key I figured going the extra mile for a better experience is totally worth it.

We always want to remove first and then add, this is because the way path is created by primary keys as mentioned. If we add a node with the same path (change in order) and then call remove it will delete both the old and new ones. Also notice the two functions deal with somewhat different issues – the ‘undo’ must clean up additional transactions created by the API methods, while the redo takes advantage the latter in order to have transactions back to the log. Furthermore, processing the ‘addnode’ transaction first means more complications when saving an index, since we need the ‘indexMap’ to still contain the old node’s place when undoing the ‘removenode’, so this calls for saving that index to the side and updating it last. Also to gain initial index we hook up to the node dropping event to save it:

Note that caring for node index in this implementation only has meaning on the client-side, but I think it’s nice to have. Check out below the (slightly large) capture of the Undo/Redo in action – note how the transaction log gets cleared when you undo and the ‘Tofu’ node is back under produce, but the redo stack now holds transactions for it. And as expected it shuffles the two moved nodes afterwards as well:

Resources

As usual the Ignite UI Tree Documentation and jQuery API Reference and detailed samples are at your disposal to draw code and knowledge from!

For the batch updating and undo/redo sample grab the ASP.NET MVC demo project ( with everything from here included in with both MVC helper and script-only demos). Make sure to check that one out!  You would need at least a trial version of Ignite UI so hit the banner below if you are still lacking one.

Also you can go for fiddling right now on JSFiddle: Ignite UI Tree Drag & Drop + Updating demo.

If this has caught your interest and want to know what other cool tricks you can do with this feature – once more the Tips on Drag & Drop with the Ignite UI Tree await!

Summary

Yet another spin of the in-depth look at the Ignite UI Tree’s Drag and Drop feature. With some insight on the API methods used we were able to use this interaction feature as editing one, by implementing batch updating with the help of the underlying data source. Building on top of that you can actually manipulate the log and use the very same API to add Undo / Redo functionality. And since we change the actual log, transactions going to the server for saving will also be in tune! Again it’s all thanks to the building blocks of the feature and their extensibility!

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

We’ve stated time and time again that the Ignite UI controls based on jQuery and jQuery UI are pure client-side scripts that are completely server agnostic (meaning they do not depend on the back end). So we keep saying you can use them everywhere, yet time limits the number of platforms we can cover with guides and such. There has been one article on Using jQuery Grid with PHP pretty much. We figured it might be a good time for some more. PHP itself is so tightly integrated with web content (petty much described as HTML-embedded) that every html snippet and sample you find is yours for the taking. Considering that along with JavaScript, they are the two most widely spread scripting languages, I would also assume if you do Web with PHP you probably have a decent experience with both. You can tell

It’s all good and merry when integrating with your own site’s internals, but what if you are developing for something like WordPress? It’s extremely popular and powers a decent chunk of the top websites. The thing about WordPress is that perhaps part of its popularity is due to the fact that it provides a very powerful, but at the same time very user-friendly platform to build sites on – and by that I mean a very easy interface for non-programmers, extensive admin panel, widgetized themes and a plethora of extensions. That also means that if you are in the role of the programmer you have a lot of demand and a platform to develop for

General

I think everyone are/will be quite pleased with the ways you can add functionality to WP – they all have their strengths in certain areas, but more on that later.

Let’s start with the general concept of running an Ignite UI widget in a page – you need jQuery, relevant jQuery UI and Ignite UI scripts (an awesome place to get a list of requirements for each control is to visit the Ignite UI API Reference where each control’s home page gives a detailed ordered list of dependencies or sink yer teeth in the Documentation). As you probably already know the reason I mentioned PHP is because WordPress is built with it – that means you could probably just go and output whatever and wherever you like. However, the beauty of it is that you don’t have to – WordPress kindly offers to handle a lot of that for you:

• Don’t just output script tags! Use the wp_enqueue_script() function instead – it has jQuery and jQuery UI scripts already registered, so you can simply use something like:
  

  wp_enqueue_script('jquery');

  
  There are a ton of plugins or widgets that use jQuery  already and the great deal about this is that the function will not add the library again if it’s already been included - trust me you do not want to double it, I've seen that cause errors, plus you don’t really want to try and check for yourself either, so please use this instead. Also provided are a number of additional settings to provide source location for the script and even define dependencies. Preferably save the Ignite UI control initialization scripts with whatever options you need in a script file and also queue it in the same way.
  On a side note, there’s also wp enqueue style().
• Be mindful where you include - Note that usually, scripts are added to the head of the document, depending where you do the call, however WordPress will allow mid-page calls to the function that will output the scripts in the footer instead. There’s also option to include in the footer. Use the available action and filter hooks to properly initialize those. Also make use of is_admin() to skip unnecessary script loads in admin panel, unless that is your goal.  

• No conflict– in the queue function reference there’s a chapter on the jQuery noConflict more– please be aware of that if you are using the default library. Also, in case you are wondering – Ignite UI widgets are indeed properly wrapped in a self-executing function to guarantee safe usage of ‘$’ in private scope. So basically you should only worry about your own code.

What are your options?

So how can leverage the extensibility WordPress provides? Do think of the following as concepts, I might end up doing some, but for now everything below is strictly an idea.

Shortcodes

I think those are by far the easiest to get going ( plug they are decently user-friendly) and WordPress gives you a Shortcode API. As you can see there a short code will be kind of good for adding Ignite UI widgets where you don’t require a lot of settings from the user (you provide most of the defaults) or the control itself is fairly easy to set. That is because, while the API does provide a method to have attributes, asking someone to enter 20-ish or more of them is just wrong. An example for the igRating can look like this:

[ig-rating value="1"]

And through the add_shortcode() you assign a function to this tittle that WordPress will call to replace the tag.

On the flip side, short codes can be added anywhere (pages, posts) so you don’t have to worry about proper hooks for those. The also tricky part is that the attributes don’t do camel casing, therefore you won’t be able to match the Ignite UI widget settings exactly and directly pass the encoded the attributes as options for it.

There are a lot of References at the bottom of every WordPress documantation page (which totally rocks!) so check those out, and here’s a bonus from me with an awesome video guide - WordPress Shortcode API Crash Course.

Widgets

These are also pretty popular, as their main goal is to add content and functionality to sidebars of "widgetized" themes, however since that just means sidebars are registered, so there are ways to add a ‘sidebar’ to your posts and pages (by making a new template, and then using it for new ones). Widgets are not quite as simple to implement, but again there’s Widgets API to the rescue. You have a base class to extend and a few functions to override. The end goal of course is to have something like this in the admin panel:

WordPress will be extremely kind to handle all the database work for you – serializing back and forth, and calling your functions with the ready-to-use arrays. While that totally rocks, just how many settings fields do you think would be acceptable to stick in there? I’d say not too many or you are going to have a really poor user experience. So again much like the short code – good for not-so complicated controls or when used with plenty of defaults you provide instead.

Plugins

And we reach to the most capable option to develop with – as stated the plugins “can extend WordPress to do almost anything you can imagine”. Plugins Docs can be your starting point, but there’s one that is even more interesting – the option register your own settings page with plugin options via the Settings API and have it appear in the admin panel like this:

And as you’d expect WordPress will abstract away the database plumbing – much like the Widgets options you can output a settings form and the names of inputs will become attributes of the options object you can later on request. The nicest part is that you get a whole page for your control settings ad you can really go wild here – tabs and what not and as many settings as it makes sense.

You will have to worry about hooks and what not, but I’m guessing it can be worth it.

What do you think?

So what do you think would be the most appropriate way to go with this? Do you thing that different solutions fit different controls better? Looking at the Ignite UI toolset, imagine a control being available in WordPress as whether a short code, widget or plugin – as an user, which one are you more likely to use and how? What would you do as a developer?

I’d love to hear some thoughts, so leave a comment down below or @DamyanPetev. If you have already developed anything with Ignite UI and WordPress we’d love to see your work and if you haven’t but you are interested, go for the WordPress documentation and grab yourself some UI fuel from:

Also stay tuned to see where this ends up!

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