Check The Box

by alan on July 24, 2012

If I were to pick a statement to be known as Caulkins’ Law, it would be “It’s always more complicated than you think it is”. The topic of this post epitomizes that maxim: the use of the innocuous HTML checkbox.

Checkboxes are possibly the most mundane, boring topic I could choose, but they have caused me so much pain than I’m writing this in the hope that some future Googlers might be spared. Checkboxes seem so innocent because in the beginning of your web development career, they seem so easy to use. Indeed, when you’re still writing static HTML files and CGI scripts, you just make an input tag:

<input type="checkbox" name="yes-or-no" />

Fine, but what if you want to pre-determine the value of the checkbox? Simple, you just add a ‘checked’ attritbute when you want the box pre-filled:

<input type="checkbox" name="yes-or-no" checked />
     valid XML version:
<input type="checkbox" name="yes-or-no" checked="checked" />

But that’s where the trouble starts. How do you specify that the box is “unchecked”? You don’t; there is no value of the ‘checked’ attribute that means “not checked”. The only valid value is the word ‘checked’, and if you leave it out or use something else, like ‘false’ or an empty string, the browser will interpret the mere presence of the attribute to mean that the box should still be checked. In some common web languages, like PHP or ERB, this isn’t really a problem, but under the right conditions, figuring this out can take hours.

Instead of PHP, suppose you’re using Clojure’s excellent Hiccup library to express markup in Clojure syntax, and you’re using Moustache for templates to be rendered in the client. You write Clojure code that gets rendered as an embedded Moustache template in HTML:

[:script#some_template {:type "script/html"}
    [:input {:type :checkbox :name :yes-or-no
             :checked "{{some_value}}"}]]

Now, every time you instantiate that template, the box will be checked, no matter if ‘some_value’ is true, false, null, or completely absent. Hiccup will render the ‘checked’ attribute if the ‘:checked’ key is present at all. You can’t remove ‘:checked’ from the attribute map because it’s not an actual tag being rendered on a page. It’s a template, and you need the Moustache expression because the eventual concrete tag may or may not be checked. Welcome to web meta-programming.

In the end, if you want to use this software stack in this situation, you have to do something like this:

[:script#some_template {:type "script/html"}
    "<input type=\"checkbox\" name=\"yes-or-no\" "
    "{{#some_value}}checked{{/some_value}} />"]

Ugly, but if you need to, you can feed Hiccup a raw string, and it will be sent to the browser unescaped, allowing you to dump straight HTML. You are essentially dropping the abstract notation and working with HTML as text, the way you would in PHP.

Now, realize that this isn’t the fault of the developer for not just using PHP. The problem is the weird, non-negatable semantics of the checked attribute. It’s quite a pile of technologies, but they all bring something to the table, and having the choice between straight HTML and an abstraction of it is powerful in itself. Incidentally, the same issue exists for select options and radio buttons, except that options use ‘selected’, and radio buttons also use ‘checked’. And if you want to check the box using Javascript, that code is also different from setting the value of any other input type.

It’s always more complicated than you think it is.


Capability Objects in Clojure With Reify

by alan on July 23, 2012

Hello! I’m going to try something a bit different with this post, which is going to be more technical than the ones I’ve written before. The blog has spent an extended period off the air, and in the meantime, my day-today software support activities have faded considerably, so I’m going to start writing more posts in the direction of software development. I hope you find me intriguing, if not informative!

I’m a big fan of an obscure piece of computer science called the Object Capability Model (woo!). I will probably write a future post about it, but in a nutshell, the model says that since security is about restricting access to things, you can build security into systems by only giving clients software objects that don’t do restricted things. Instead of making functions that check out a client’s access level every time they’re used, you can simply give the client an object that only has allowed methods, or “capabilities”. There are naturally some other requirements for such a scheme to work, but it can be more simple and flexible than things like access control lists.

About six years ago, I developed a capability library in Common Lisp called Consul. I never released it as a separate library, but it provided authorization on several different projects. While I don’t consider it a dead project, Consul is definitely in deep stasis, mostly because I’ve moved from Common Lisp to the new sexy of the Lisp world, Clojure. Object capabilities require object oriented programming (Consul made heavy use of CLOS), and Clojure intentionally omits typical object oriented features.

So, imagine how surprised I was when I realized that Clojure could approximate some of the important points of capabilities! The secret is the reify construct, and I’ll show you how to use it.

Let’s say that you have an object representing a person:

(def atticus {:name "Atticus Finch"
              :city "Maycomb, AL"
              :age 43
              :ssn "123-45-6789"})

This object could be a real Java object, but for simplicty we’re just using a regular old Clojure map. The SSN and age fields are restricted, and we want to control when they are accessible, so we only make subsets of this object available to other parts of our program. We’ll use defprotocol to define what capabilities we want the object to provide:

(defprotocol person
    (name [this])
    (city [this]))
(defprotocol age-access-person
    (age [this]))
(defprotocol ssn-access-person
    (ssn [this]))

Now, to create our capability objects, we use reify to instantiate anonymous classes that have appropriately implemented capabilities, and pass them wherever they need to go:

(some-func (reify person (name [this] (:name atticus))
                         (city [this] (:city atticus)))
(needs-age-only (reify age-access-person (age [this] (:age atticus)))
(needs-everything (reify person (name [this] (:name atticus))
                                (city [this] (:city atticus))
                         age-access-person (age [this] (:age atticus))
                         ssn-access-person (ssn [this] (:ssn atticus))

Note that the instances created by reify contain only the closures defined as their methods. So, you can’t peek inside them to look at atticus or its fields, since they don’t actually have any fields. Also, the closure can do more than just look up hidden fields – they can also wrap access to methods that you want to control. To use the closures, call them as methods:

(defn needs-age-only [p] (println "The person's age is" (.age p)))

Now, some caveats. This isn’t actually object-capability programming, since a number of the model’s pre-requisites are not addressed. For example – where did we get atticus? The Object Capability Model requires that the protected object have a type that cannot be created independently, so the object reference can’t be forged. Also, globally available resources are incompatible with the model, since you can’t limit their access. This is more an object-capability programming style that is meant to make the design of authorization systems easier and more dependable for the programmer, provided she is disciplined enough to only use capability objects to carry out restricted operations in her code.

A full object capability system could probably be implemented out of closures (after all, “objects are merely a poor man’s closures”), but that would amount to giving Clojure a crude object system that it was never intended to have. Using reify is a convenient way to approximate object capabilities, from a stylistic point of view. If you find this idea at all interesting, I’d encourage you to follow the above links and read about object-capability languages and operating systems. Whether you like the idea, or you think I’m completely mental, leave a comment and tell me your opinion!


Profiles Are Lame

August 21, 2010

Some time ago, I said I wanted to do some posts about mobile technology and the problems that come along with it. Mobile technology is huge right now, and will continue to get bigger as people give up their desktops in favor of notebooks, and increasingly, smart phones. The problem is that businesses still need [...]

Read the full article →

GCTS Web Hosting

August 11, 2010

This post isn’t so much an opinion piece, as an update on the GCTS business strategy. After much work and preparation, I’m very happy to announce that GCTS will be branching out into a new type of service – GCTS Web Hosting. We’ve been playing with this idea for some time, debating about whether it [...]

Read the full article →

Impatient Me

July 24, 2010

As time goes on, I’m seeing the GCTS blog evolve in my mind from a little “tips and tricks” customer newsletter to a journal of thoughts and commentary on developing the consulting business. This time, I’m going to talk about one of my favorite parts of that business: automation. It’s the process of using, and [...]

Read the full article →

Throw Me a Bone Here

July 13, 2010

A couple of days ago, I said that I was going to start a blog series on tech trends that have been affecting my own computer systems, and how I think those of you who have office networks are feeling the heat, perhaps without realizing it. I planned to do this post on the effects [...]

Read the full article →

Spinning Up

July 8, 2010

Hello, my name is Alan, and I’m one of the founders of Green Country Technical Services. After a few months of Other Things To Do, I’ve finally dusted off the GCTS website, fixed up the design, and now I’m getting on with regular posting. I started this blog intending to talk about trends and observations [...]

Read the full article →

New GCTS Commercial

October 31, 2009

Hello, and happy Halloween everyone! Starting a new business is full of exciting and interesting things, and I’m pleased at how cool one recent experience has turned out to be: our new GCTS TV commercial. We started airing it a couple of weeks ago, and it’s been pretty awesome to see our logo pop up [...]

Read the full article →

Launching Green Country Technical Services Web Site

October 12, 2009

Welcome to the newly launched Green Country Technical Services blog! This is where we will be making announcements about our services and new developments at GCTS. Check back soon or subscribe to our RSS feed, and be sure to click on the Home link to check out the main GCTS site. -Alan

Read the full article →

Articles Coming Soon!

September 6, 2009

Check back here soon for technical articles provided by Green Country Technical Services.

Read the full article →