Last year around this same time, I published a blog post about a technique I developed for creating multiple Twitter Bootstrap popovers.
I came up with the technique while building a page containing several
icons that, when hovered over with the mouse, would display different
Bootstrap popovers with explanatory text and HTML.
The other day, a commenter on the original post asked how he could
use my technique but ensure that only one popover was open at any given
time (which I took to mean that on his page the popovers were triggered
by a mouse click rather than a hover). I gave him a brief, general idea
of how to approach it (off the top of my head) but he wasn't clear on
what I meant, so I decided to do a post on it.
One of the features of the jQuery DataTables plugin is that you can use the configuration option "bStateSave" to store the current view of the table (the sort order, the number of rows displayed, the filter term, etc.) in a cookie, so if the user navigates away from the page then comes back, the table view is the same as how they left it.
However, if your website or web application stores the state of several DataTables, and a user hits all those tables faster than those cookies can expire (their default lifespan is 2 hours but can be customized with the "iCookieDuration" option), the user could hit the browser cookie size limit and start seeing errors on your site. I ran into this problem today with an application I've been working on.
Fortunately, starting with version 1.9, DataTables provides functions that let developers intercept the process of saving the table state and reloading that state, and the plugin author provides a documentation page on how to use those functions to store the state data in localStorage, which in most browsers allows you to store a few MBs of data per site (far more than the 4K limit per site for cookies):
In my case, I decided that I would store the state data in sessionStorage rather than localStorage, but the principle was the same.
In case you missed it, last week the jQuery team announced the launch of the long-awaited jQuery Plugin Registry (http://plugins.jquery.com/). This new site is designed to address the issues that were present in the old jQuery plugins site and make it easier for plugin authors to share their creations via an authoritative listing.
I like what they ended up doing with the registry. Instead of hosting copies of the plugins, it leverages GitHub. Plugin authors put their plugins up on GitHub, add a manifest JSON file to their project that provides descriptive metadata about the plugin, and then add a webhook for the registry to the GitHub project (all of these steps are well-documented on the registry site). Once all that is set up, every time someone creates a new GitHub tag for the plugin and pushes it up to the repo, GitHub will notify the plugin registry of the change and the registry will be automatically updated. In other words, updating the project on GitHub updates the plugin registry as well.
Finally having a robust centralized, official listing of jQuery plugins is really going to help the plugin ecosystem. It'll hopefully give lesser-known plugin authors more exposure and give plugin users a central place to search for plugins that returns results with quality, up-to-date information.
I've already added my recently updated dirtyFields plugin to the registry. Not sure if I'll add my older, simpler plugin for counting characters/words in a textarea; I'll have to look and see what's already out there in that regard to see if my implementation fills a niche need for that sort of thing.
I've made some updates to my dirtyFields jQuery plugin. Here's the rundown:
Added two new public functions:
getDirtyFieldNames() returns an array of all currently dirty fields.
updateFormState() checks the clean/dirty state of all form fields in the specified container
Made two changes to how the CSS class denoting a dirty/changed form is applied:
Added a new configuration option ("self") to apply the class to the actual form element.
Split the single option for applying a style to a changed text input and select drop-down into two separate options for granular control (if you used the textboxSelectContext option with a previous version of the plugin, you will need to update your code).
Added three new configuration options to control plugin behavior:
The denoteDirtyFields option controls whether or not the dirty CSS class is applied to the form elements that are dirty/changed.
The exclusionClass option specifies the name of the CSS class that, when applied to a form field, will exclude that field from being processed by the plugin.
The ignoreCaseClass option specifies the name of the CSS class that, when applied to a form field, will instruct the plugin to do a case-insensitive evaluation of the current and original states of the field.
All of these changes were implemented in response to code suggestions made a team of developers (listed in the GitHub readme.txt file) who modified the plugin to meet their specific needs in one of their intranet sites.
One of the functional requirements for the voter registration application I blogged about recently was that the application should not allow further registrations between the registration deadline (October 16 at 9pm) and a date after the election specified by the state Board of Elections. For the initial run of the application, I simply hard-coded the deadline and restart date into the application logic, knowing full well I couldn't leave it that way unless I wanted to personally change the code year after year....which I don't.
So this week I set out to write a tool within the administrative interface of the application that would allow a non-programmer to update the deadline and restart date every year. The jQuery UI Datepicker widget is my tool of choice when it comes to having users enter or edit a date, but I've used a few different approaches to having users enter a time of day. This time around, I decided to see I if could find something comparable to the Datepicker widget for setting the time.
What I found was a rather sweet plugin called the Timepicker Addon that adds a set of time controls to the jQuery UI Datepicker. If you customize your jQuery UI download to include both the Slider and Datepicker widgets, you can present the time controls as sliders, like so (without the Slider widget, you get select boxes):
The plugin comes with a number of configuration settings so you can do things like adjust the time increments, change how the time is displayed, and allow the user to denote the time zone associated with the time value. Once I had the plugin configured the way I wanted, I simply had to write some code to validate the date and time string submitted from the form field, and I was done. Very cool.