Quick Tip: Backbone Collection Validation

Often times I find the native Backbone Collection implementation to be lacking when compared to it’s Backbone.Model counterpart. In particular, Collections generally lack in terms of direct integration with a backend persistence layer, as well as the ability to validate models within the context of the collection as a whole.

Fortunately, such short comings can easily be circumvented due to the extensibility of Backbone’s design as a generalized framework. In fact, throughout my experience utilizing Backbone, I can assert that there has yet to be a problem I have come across which I was unable to easily solve by leveraging one of the many Backbone extensions, or, more often than not, by simply overriding Backbone’s default implementation of a given API.

Validating Collections

Perhaps a common use-case for validating a collection of Models can be found when implementing editors which allow for adding multiple entries of a given form section (implemented as separate Views), whereby each section has a one-to-one correlation with an individual model. Rather than invoke validation on models from each individual view, and manage which model’s are in an invalid state from the context of a composite view, it can be quite useful to simply validate the collection from the composite view which, in turn, results in all models being validated and their associated views updating accordingly.

Assuming live validation is not being utilized, validation is likely to occur when the user submits the form. As such, it becomes necessary to validate each model after their views have updated them as a result of the form being submitted. This can be achieved quite easily by implementing an isValid method on the collection which simply invokes isValid on each model within the collection (or optionally, against specific models within the collection). A basic isValid implementation for a Collection is as follows:

As can be seen in the above example, the Collection’s isValid method simply invokes isValid on it’s models. This causes each model to be re-validated which, in turn, results in any invalid models triggering their corresponding invalidation events, allowing for views to automatically display validation indicators, messages, and the like; particularly when leveraging the Backbone.Validation Plugin.

This example serves well to demonstrate that, while Backbone may not provide everything one could ever ask for “out of the box”, it does provide a design which affords developers the ability to quickly, easily, and effectively extend the native framework as needed.

GitHub Quick Tip

Recently, I was looking for a simple way to view an html page which is part of a GitHub project’s source. In particular, I wanted to provide links on the Backbone.EventBroker project’s main page so users could run the specs and view the example.

Fortunately, as is the case with most things on GitHub, this is quite easy to accomplish; requiring nothing more than appending the URL of the page in the projects source to the http://htmlpreview.github.com/? query string:

Simple and useful indeed!

Clearing Web Notifications Permissions in Chrome

When implementing features which leverage HTML5 Web Notifications, specifically in Chrome, it can be rather convenient to have the ability to clear notification permissions from the host for which the feature is being implemented.

As would be expected, Chrome allows for easily managing any setting; however, one needs to navigate through quite a few of Chrome’s settings in order to locate Web Notification permissions, the path to which being:
Settings > Show advanced settings… > Content Settings > Notifications > Manage Settings…

Navigation of settings can be simplified by using Chrome’s Search box, which allows for quickly navigating to any specific setting:

While Chrome’s settings Search feature is quite useful, it still requires more interactions then desired. Fortunately, there is an even simpler approach for quickly accessing a specific setting, in this case, Notifications.

Simplifying Clearing Web Notification Permissions

Web Notification Settings can be directly accessed for all hosts via the following path:
chrome://settings/contentExceptions#notifications

As with any URL protocol, the above path can be bookmarked, allowing for easy and convenient management of Notifications.

Bookmarking Chrome Settings

While the focus here may be on the topic of managing Web Notification settings, it is important to note that any Chrome setting can be bookmarked as a convenience shortcut for quickly navigating to any given setting. For instance, Chrome’s cache setting can be bookmark at:
chrome://settings/clearBrowserData

Then, commonly used settings can be accessed simply from their respective bookmarks:

Simplifying Testing of Sign-up Processes

When testing the various steps of account sign-up, creation and activation processess, one must be mindful of designs which call for unique email addresses to be confirmed for each new account. While this is a generally accepted approach, it does pose a slight challenge when end-to-end testing requires email activation from the address with which the account was created.

Creating multiple Accounts under the same Email Address

Recently, while implementing an account registration feature, I was looking for a simple means of creating and testing multiple user accounts against a single email address, so as to allow for continuous testing without the need to use different email addresses for each test.

Fortunately, a few clever solutions have been available all along in Gmail which can be leveraged for this very problem (in addition to others).

The Plus (+) Trick

Perhaps the simplest means of creating or generating unique email addresses for account creation which will all be sent to the same email address is to leverage the Plus (+) Trick.

For instance, suppose you are testing account creation and activation and want to confirm the sign-up process at someuser@gmail.com. Typically, one would want to test this feature multiple times – either by means of automated testing, manual integration testing, or the like. In order to test the account creation feature continuously using the same someuser@gmail.com account, one can simply create new accounts by appending a plus (+) to their gmail user name, and postfix a unique string of charachters to the plus sign:

In this example, emails sent to any of the addresses above would all go to someuser@gmail.com. With this in mind, it is quite easy to continuously test account creation processess without the need to use multiple (real) email addresses.

The Dot (.) Trick

As with the Plus (+) Trick, similarly, the Dot (.) Trick can also be employed to test account creation under the same email address.

For instance, to test an account creation and activation process feature continuously using the same someuser@gmail.com account, one can simply create new accounts by inserting a dot “.” within their gmail user name:

In this example, emails sent to any of these addresses above would all be sent to someuser@gmail.com.

Concluding Thoughts

As can be seen in the above examples, both the Plus (+) Trick and Dot (.) Trick, respectively, can be used to create and test account sign-up and activation processes against a single email address, greatly simplifying testing.

While the Dot (.) Trick is quite useful, it is obviously limited to a finite combination of pseudo-unique email addresses, and thus, it is better suited for fewer testing scenarios.

For more extensive testing scenarios, the Plus (+) Trick is much better suited, as it allows for seemingly infinite permutations of the same email address, and is ideal for generating addresses from which account creation is to be tested.

Function Modules in RequireJS

Having leveraged RequireJS as part of my preferred client-side web stack for some time now, I find it rather surprising how often I recall various features from the API docs which I have yet to use, and how they may apply to a specific solution I am implementing.

One such feature is the ability to define a module as a function. While at first this may seem a rather basic feature, and indeed it is, there are quite a few practical purposes in which returning a function as a module definition can prove useful.

Function Modules

As one may expect, returning a function as a Module in RequireJS is rather straight-forward. For example, a simple random function can be defined as a module as follows:

Then, the function module can simply be invoked as follows:

Function Modules as Factories

Perhaps a more practical example of implementing a function module is in the context of a Factory Method.

For instance, a function module can be used as a convenient means of creating a specific type of object on a clients behalf based on certain conditions.

Take (an intentionally simple) example of a function module which, given a specific role type, returns a corresponding view implementation (in this example, a Backbone View) for an Editor feature:

Client code can then simply invoke the factory in order to retrieve the appropriate Editor view implementation based on the specified role type:

Defining modules as functions which serve as factory methods can help simplify client code implementations, as the responsibility of determining the type of object to create, configure, etc., can be delegated to a dedicated object; thus allowing for simpler designs which better facilitate code reuse, testing, and maintenance.

As a general rule of thumb, I typically reserve implementing modules as functions for cases in which a package level method would be appropriate, or for factory implementations. However, there are other scenarios in which function modules may apply, and so they are certainly worth noting.

You can fork the above example here.

HTML5 Input Elements on iOS

Perhaps some of the most important UX considerations to make are those surrounding the simplicity with which forms can be completed. This is especially important when taking into account the constraints of Mobile devices.

Input Elements and the iOS Keyboard

While implementing a form for a Mobile Web Application, I found myself in need of a way to control some of the default behaviors of the native iOS Keyboard. Specifically, I found it rather inconvenient on the user’s part to require manual closing of the keyboard of any kind, especially after submitting a form. I also found it inconvenient to have to manually turn off auto capitalization on input elements, or having to work around the default auto-correct behavior on input elements.

Fortunately, these issues (as well as others) have solutions which are readily available, both natively and programmatically.

Turning off auto-caps

By default, the iOS Keyboard displays with Caps Lock on for the first charachter on input elements of type text. For certain use-cases, such as entering usernames, this may not be desirable.

Caps Lock can be turned off by simply defining an autocapitalize attribute with a value of off on input elements:

Turning off auto-correct

As with with Caps Lock, in iOS, by default, input elements of type text have auto-correct enabled. For certain use-cases, again, such as entering usernames, this may not be desirable.

Auto-correct can be disabled by simply defining an autocorrect attribute with a value of off on input elements:

Automatically closing the Keyboard

When submitting a form, at times, the iOS Keyboard may not automatically close. This is quite a usability issue as Users should not be required to manually close the Keyboard for use-cases in which they would otherwise not expect the need do so.

A simple solution for this can be implemented by invoking the blur method on document.activeElement, which effectively allows one to programmatically hide the keyboard:

HTML5 Input Attribute Types

In addition to controlling the default behavior of the iOS Keyboard, specific types of Keyboards can be invoked simply by defining a supported HTML5 input element type.

The following examples demonstrate just how easy it is to display a context specific keyboard:

The Email keyboard can be invoked via the email input type:

The URL keyboard can be invoked via the url input type:

The Telephone keyboard can be invoked via the tel input type:

The Numeric keyboard can also be invoked via the pattern attribute, the value of which being either of the following Regular Expressions [0-9]* or \d*:

You can try the above examples here, or view the gist.