Time span sliders in jQuery

May 28, 2011 15 comments

I’ve been working on prototyping a new application that needed a way for users to schedule things in spans of time on multiple days. It should be quick and easy for people to pick arbitrary time spans on each day of the week. The main use case is to set a day time block, during business hours for example, or a block that excludes business hours. Someone might schedule the time span from 8am to 5pm, or they might schedule it to end at 8am and then start again at 5pm. I looked around but didn’t find any examples of doing anything like this that I liked.

I settled on a slider that you can invert. So you can set the range from 8am to 5pm, then click on a check box that flips the slider to mean everything except for 8am to 5pm. It needs to be visually obvious what this is doing, so the slider and text needs to reflect what is happening. I think the result is fairly easy to use and very workable.  The layout looks something like this:

The other thing I wanted was to be able to drop the whole thing in a page easily based on code in one place. I anticipate it will be used in more than one location within the application. So I wanted to construct it as a jQueryUI widget that basically wraps the standard slider widget. I didn’t try to make it portable beyond this app. There are a few things I’ve done here that you wouldn’t want to do if you were making a normal jQueryUI plugin.  For example, it carries the HTML for laying out the text and sliders within the widget.  I think its illustrative for a prototype, but not elegant.

Posts on doing multiple sliders or time based sliders are not easy to find. The best one I found was from Marc Neuwirth. That post saved me some time in figuring out how to deal with the times on the slider. There is also an improved slider on the Filament Group’s site, but it doesn’t really answer the basic needs I had.  The fact that I had a hard time finding examples from other people who’d already done the same thing is what prompted this post.

For a time slider, we need to convert the times to integers so we can use them for slider values. To convert the time to an integer, we split the time into hours and minutes, multiply the hours times 60, and add back the minutes. We do the reverse to turn the integer into a formatted time for display. In the code below these operations are done in two functions, named formatTime and getTime. These are single use functions I don’t have a need for elsewhere, so I’m carrying them inside the narrow scope. If I ended up having a similar need somewhere else I’d refactor that out to make it usable elsewhere.

Since I’m making a jQueryUI widget (sort of), I start with the basic self executing function and the widget factory method.


    $.widget("ui.timeslider", {


To that, I need to add the options object, which will allow us to set our options for the widget and also double as the options we’ll pass to the individual sliders. That last bit gets a little sticky, because we’ll have a changing scope as we deal with events within seven different slider (sub)widgets. Usually I wouldn’t put the whole callback function in the options definition, since its harder to read and maintain, but its easier to make it portable to each of the sliders this way.

options: {
    animate: false,
    days: ["monday","tuesday","wednesday","thursday","friday","saturday","sunday"],
    distance: 0,
    max: 1440,
    min: 0,
    orientation: "horizontal",
    range: true,
    slide: function(event,ui){
        function formatTime(time){
            var hours = parseInt(time / 60 % 24);
            var minutes = parseInt(time % 60);
            minutes = minutes + "";
            if (minutes.length == 1) {
                minutes = "0" + minutes;
            return hours + ":" + minutes;
        var startTime = formatTime(ui.values[0]);
        var endTime = formatTime(ui.values[1]);

        var selector = "#"+this.id;
        $(selector + "-time1").val(formatTime(ui.values[0]));
        $(selector + "-time2").val(formatTime(ui.values[1]));
    step: 5,
    value: 0,
    values: [360, 1080]

Most of these options are the standard slider options. The only addition is the days array, which we’ll use to add the individual days to our results. Putting it in the options this way lets us pass in a different set of days if we wanted to (maybe Monday through Friday are more appropriate in some places). The slide callback is basically a typical callback for the slider widget. The id based selector will make more sense in a bit.

The rest of the widget is all in two methods: _create and _sliderhtml. _sliderhtml just holds our html to build the containers for the individual sliders. The underscore at the front of the method names are how we tell the jQueryUI factory that they are private.

_sliderhtml: function(day){
    var displayday = day.charAt(0).toUpperCase() + day.substr(1);
    var html = ""+ 
        '<div class="fieldrow spacer">' +
            '<div>' +
                '<label for="'+day+'-time" class="inline">'+displayday+':</label>&nbsp;' +
                '<span id="'+day+'-midnight1" style="display:none">midnight to</span>&nbsp;'+
                '<input type="text" name="'+day+'-time1" id="'+day+'-time1" value="6:00" class="blended"> - '+
                '<input type="text" name="'+day+'-time2" id="'+day+'-time2" value="18:00" class="blended">&nbsp; '+
                '<span id="'+day+'-midnight2" style="display:none">to midnight</span>&nbsp;&nbsp;&nbsp;'+
                '<span>Except <input type="checkbox" name="'+day+'-except" id="'+day+'-except"></span>' +
            '</div>' +
            '<div id="'+day+'"></div>' +
    return html;

That’s not pretty, and the wrapping displayed here makes it look even worse. This is special use widget, intended for one application. I wouldn’t build more general use widgets with the HTML like this, because you have to edit the widget code to change the layout, but its fine for my limited purpose here. This is the HTML for one slider. We’ll pass it the day from the days array in the options and use the day name for our field names and element IDs. We change the first letter of the day’s name to upper case to make the label.

_create is the standard method that will be used by the jQueryUI to construct our widget. It looks like this:

_create: function(){

    var self = this,
        o = this.options,
        dayslength = o.days.length;
    o.timeslider = this;

    function getTime(time){
        var times = time.split(':');
        time = (times[0] * 60) + parseInt(times[1]);
        return time;

    for(var i=0; i < dayslength; i++){
        $( "#" + o.days[i] ).slider(o);
        $( "#" + o.days[i] + "-time1" ).bind("change",function(){
            var slider = "#" + this.id.substr(0,this.id.length - 6);
            var newval = getTime($("#"+this.id).val());
            if(!isNaN(newval)) $(slider).slider("values" , 0 , newval);
        $( "#" + o.days[i] + "-time2" ).bind("change",function(){
            var slider = "#" + this.id.substr(0,this.id.length - 6);
            var newval = getTime($("#"+this.id).val());
            if(!isNaN(newval)) $(slider).slider("values" , 1 , newval);
        $( "#" + o.days[i] + "-except" ).bind("change",function(){
            var excl = "#"+this.id;
            var sliderlength = excl.length - 7;
            var slider = excl.substr(0,sliderlength);
            var exclude = $(excl).is(":checked");
                $(slider + " div").addClass("ui-widget-content");
                $(slider + " div").removeClass("ui-widget-header");
                $(slider + "-midnight1").css("display","inline");
                $(slider + "-midnight2").css("display","inline");
            } else {
                $(slider + " div").addClass("ui-widget-header");
                $(slider + " div").removeClass("ui-widget-content");
                $(slider + "-midnight1").css("display","none");
                $(slider + "-midnight2").css("display","none");

The interesting part, and basically the whole reason for the widget to exist, is in the for loop in this method. self.element is the element from the selector in our page. So we might create the widget like this:
In that case the DOM element with “scheduler” as the ID will be self.element within the _create method. We iterate through our options.days array and append the html from _sliderhtml for each day in the array. Then we put a slider widget in each of those blocks of HTML (line 16 above), passing it the same options array we’re using. It has the extra days array, but the slider widget will ignore that. The rest of the loop is adding event bindings to the three input elements embedded in our HTML.

The first two input elements hold the times. This makes grabbing the values extremely easy, because we have an input element with an ID. We put the values in these fields in the slide callback in the options (line 23 and 24 in the second code block in this post). Here we’re binding an onchange to these elements. That allows a user to click on the times and type in a new value, which will move the slider to what they typed. It might be that nobody will ever do that, but I think it’s a nice feature.

The third event we’re binding is a change event to our checkbox. The string manipulation on lines 29 and 30 is identifying the various elements that make up our layout. On line 31 we see if the checkbox is checked or not, and then depending on that we set styling on the slider.

As a last step, I added another checkbox at the top to disable the whole thing, but that’s not actually in the widget. When you click the checkbox it does this:

    } else {

This highlights the benefits of using the jQueryUI widget factory for this exercise, if that wasn’t clear already. By using the widget like this, we get the disable and enable methods, and all the other standard widget methods built in.

This is prototype, and I’m not sure yet if it will make it into the production application. If it does (and I remember) I’ll update this to show it used in context. If it gets into production it will likely need some refinement. For example, the checkbox might be better as a button and “Except” is not the right label, and there are a few other things I’d tweak. In the meantime, I hope this is useful for someone.

Categories: javascript, jQuery

Learning and community life cycles

May 19, 2011 Leave a comment

My first round of experience learning a web development environment was in the 90’s, when I needed new ways to deliver financial reports to department managers and built web reporting using ASP pages on Windows NT servers. It was live. It was on demand. You didn’t need to run a special client program to get your reports. It was one of my first experiences of providing people with a tool that they hadn’t realized they needed, but within a few weeks everybody was convinced it was essential to getting their work done.

I jumped into the online communities (basically email back then) and asked and answered questions in various groups. I quickly realized that PHP fit what I was trying to do better, and I moved to the PHP community. I learned a lot from those groups. My personality is to listen more than I talk, both online and off, but in those days I was excited about what I learned and wanted to help others learn it too.

It didn’t take me long to notice that people ask pretty much the same questions over and over. Many groups online are used largely by people who are learning a new technology. That’s a critical function, and its a good way to distribute the learning. Like many people, I got tired of answering the same questions, and started thinking maybe people should at least make an attempt to look at the group’s archives.

Since I first started, we’ve moved through forums, blog posts with arguments in the comments, and then to sites like stackoverflow.com and microblogging. They are all useful, and all of these formats for distributing information and learning still continue to some extent even as they are replaced by newer models.

Its fun to go through the life cycle with each new technology. You learn something new, hit snags, and go looking for where the community is. Its even more fun when the community is new and the best practices are still being fleshed out. The beginnings of the CouchDb and Node.js communities were more recent examples of that for me. I didn’t catch either of those waves right at the beginning, but I was fairly early. True to my personality, I tend to listen more than talk, but I enjoy the discussions of sorting out the best way to do things.

The great thing about the early days is that the questions aren’t old for most anybody. Not that long ago the package manager for Node wasn’t settled, and there were discussions about the best way to handle that need. Now npm is the standard, and the question is fairly well settled. People still raise the question of whether it should work differently, but most of the questions have been answered. At least for the moment, npm’s place in the Node.js world is fairly settled. In this case, it happened fairly quickly.

Each generation of developers, of course, reinvents it all. Before long you start to see the same discussions popping up in every community. I’m amazed by people who continue to patiently answer the same question again and again. I don’t have the patience for it. I am much more tolerant of helping people in one on one, mentoring new developers in my team, especially when the new guy is really learning.

In Node, people get caught by async programming, and look for ways to make it work differently. Maybe at some point people will come up with a new paradigm, but Node is async and uses callbacks. If you don’t like that maybe you’re on the wrong platform. In Couchdb people get caught on how to construct views, and whether you can make views dependent on external conditions like the contents of other documents. Someone explains again why it doesn’t work like that. Some discussions never die, like when people find new ways to do things insecurely or rediscover familiar patterns. I’ve recently seen some discussions about dependency injection in PHP that seem rather worn to me.

The communities as a whole go through the same cycles too. People from the Erlang community might notice that many of the discussions and debates in the Node.js community are struggling with issues Erlang had to solve during its earlier stages. Languages evolve and have to struggle with “new” issues that are familiar to other platforms, like when PHP adds new pieces of the OOP puzzle and new debates about typing and inheritence in Java erupt in new contexts.

The world in general owes a great deal to all of the people who work through these cycles, and especially the role filled by people who seem to tirelessly answer the newbie questions. We’re all starting somewhere, and usually we find ourselves learning new things fairly often as the paradigms change. I’ve been through a few generations of PHP and MySQL, but I’m newer to CouchDb and Redis. The cycles repeat, but not exactly. Every once in a while something truly new emerges and things progress. That’s a side effect of the same challenges being faced again and again. Every once in a while, someone asking the same question the billionth time does come up with a novel answer. Then we wonder how we ever got by with the answers we all accepted before. Other times people give a name to something people have been doing for a while. Things move on. Technologies and people come and go. The tools we have now are worlds beyond what we had before. What’s next? Who knows, but there will be people learning it, and asking questions, and someone will be tirelessly answering the new questions for the billionth time. To the people who ask the same questions until the answers finally do change, and to all those people who answer the same things again and again: Thanks!

Categories: development

Async doesn’t have race conditions

April 15, 2011 Leave a comment

I’ve been noticing comments about race conditions in async code, most specifically javascript used server side as in node.js. As someone who has written more lines of blocking code than I care to think about, I can relate to the angst of people trying to make the mind bending transition to thinking asynchronously. I think that just the name “race condition” is an artifact of the age of blocking code. There are no race conditions in the async world. The term is about bugs in blocking code. In async code there are no races, because it isn’t about getting done in order, its about getting done when you’re done. Thinking in terms of avoiding race conditions isn’t about bugs, its thinking in the wrong paradigm. There is no spoon.

Categories: javascript

Testing variable types in Javascript

March 5, 2011 1 comment

Anyone who has written more than a handful of lines of Javascript has found a need to find out the type of a variable. A quick search on their favorite search engine or in their reference book turns up typeof, which indeed tells you the type of a variable. It works great, except if you’re looking for arrays, null, or NaN.

The typical way that typeof is used is in tests:

var my_string = "llamas";
var my_number = 42;

if( typeof my_string === "string" ){ 
   // do something with my string

if( typeof my_number === "string" ){ 
   // do something with my number

This type of test works well for strings, numbers, functions, and undefined. You most often see it used for the first three of these. Most people check for undefined more directly:

if( something === undefined){
   // treat it like it isn't defined

This is particularly useful if you are wanting to know whether an argument for your function was included when the function was called.

var myfunction = function(foo){
    if(foo === undefined) foo = "bar";
    // now we can do something with it, knowing that it is defined.

So, what do you do if you have a variable that might be an array or an object, and you need to know which it is? Using typeof doesn’t help, because it tells you that it’s an object either way. It is an object either way, actually, but that’s not very helpful.

The easiest test between a non-array object and an array is by checking for length. Arrays have a length, non-array objects do not. So if typeof says its an object, and its length !== undefined, then it is an array.

NaN is a special confusing case. NaN is a value representing “Not a Number,” except that of course typeof says that NaN is a number. It is useful for working with messed up math and bad dates, both of which are best detected as quickly as possible. NaN is returned by several Javascript methods such as parseFloat and parseINt. NaN is never equal to any number, including itself. So to test for NaN you use the aptly named isNaN(testValue), which returns true if testValue is indeed not a number.

Putting all this in a simple function that you can use to find the type of something is fairly easy:

  return (thing === null) ? "null" : 
    (typeof thing == "object" && thing.length !== undefined) ? "array" : 
    (typeof thing == "number" && isNaN(thing)) ? "NaN" :
    typeof thing;

If there’s a law against abusing the ternary operator anywhere, that is sure to break it.

One other thing worth noting about testing variable types is testing booleans. Using typeof we get “boolean” as the response if the operand is actually (===) true or false. So the following variables are all boolean, according to typeof:

  var yes = true;
  var no = false;
  var another = ( 1 == 2 );
  var tistrue  = ( yes !== undefined );

However NaN, null and undefined, even though they test as false, aren’t boolean according to typeof. All of these test as false:

( null )
( undefined )
( false )
( NaN )
( 1 == 2 )

But only one of them (false) has a typeof Boolean.

Categories: javascript

Setting styles in Google Apps Scripts

February 8, 2011 2 comments

I recently wrote a post reviewing Google Apps Scripts. Buried in that post was a code snippet that showed my workaround for the lack of CSS or global styling in Google Apps Scripts.  The problem is that it is in the middle of my venting about some of this service’s limitations, and most people will likely overlook it.  So I’m editing that post and putting that piece of it here on its own.

Google Apps Scripts doesn’t allow you to work with CSS at all.  Instead, they provide a mechanism for setting in-line styles as style attributes to your HTML elements.  This is done by using the setStyleAttribute method, which is available on several of the classes.  This method takes two string arguments, a style name (“line-height”, “font-size”, and so on) and the value for that style setting (10px, 1.1em, 90%, ‘bold’, etc).  These aren’t CSS styles, they are inline style attributes.  Its been a while since I’ve worked with this attribute, and I may have forgotten some of what I once knew about using these.   I found that it didn’t work well to set a “font” attribute to “110% bold serif,” you needed to set that with three separate setStyleAttribute calls.  You can chain these, which is still verbose but does make it somewhat easier.

var label = app.createLabel("Text for the label").setStyleAttribute("font-size","110%").setStyleAttribute("font-weight","bold");

That works fine, except that you end up with LOTS of setStyleAttribute calls throughout your script, and if you want to change something uniformly you’ll be copy and pasting all over the place.  That gets old fast.  So I wrote a little function as a workaround for this issue, and it seems to work reasonably well.

First, I created an object to hold my global styles

var appStyles = {
  "tableheaders": {
    "font-weight": "bold",
    "font-size": "1.1em",
    "padding": "0px 5px 0px 5px",
    "text-decoration": "underline"
  } ,
  "listtable": {
    "border-top": "1px solid #CCC" ,
    "margin-top": "6px",
    "width": "99%"
  "helptext": {
    "font-size": ".9em",
    "color": "#999"

Actually, pasting that in I realized that you don’t need the quotes around the property names. My fingers have been typing too much JSON. That does work as it appears there though, and its what I’ve tested, so I’ll leave it for now.


The next part is the function to apply the styles, uncreatively called applyStyles:

function applyStyles(element, style){
  if(!element.setStyleAttribute || !(style in appStyles)) return element;
  for(var attribute in appStyles[style]){
    element.setStyleAttribute(attribute, appStyles[style][attribute]);
  return element;

Many of the classes in Google Apps Scripts support setStyleAttribute, but not all. So we’re checking before we try to use it. Then, we iterate over the attributes in the appStyles object and apply the styles that match the passed in style name to the element. You can pass any element that supports setStyleAttribute to this function and it will be styled, and instead of copied styles all across your script you have one place to tweak the style headings.

This isn’t an ideal solution, and if I was going to use it much I’d probably do more with it. However, it is a start at a way to turn unmanageable styles in Google Apps Scripts into something you can work with and maintain.

Categories: javascript