Firstly, those notes to self I mentioned last time have been applied. You can see the results here, or more specifically, here among other places. Those used to be separate functions that each edited specific things, rather than each calling out to one actual editor. Also, the countItem and commentItem pieces were one function that accepted multiple Maybes and only applied the relevant ones. That was more complicated than it needed to be, so it has been separated into what you see there. Thinking about that function more thoroughly also pointed me to a bug I had previously missed|1|.

Secondly, I ended up having to put together two front-ends; an Angular-based page and something a bit more traditional with jQuery. The reason was that the Angular.js version refused to work on my phone for some bizarre reason. It showed the intro screen fine, and displayed auth errors like it was supposed to, but refused to show the main screen on a successful authentication. I have no idea why that was, but since half the point of this app was that I could check it from my phone on the way from work, it wasn't going to fly. Luckily, the API-friendly back-end technique I'm trying out here made it a breeze to create a new front-end without touching the rest of the application. The changes involved a couple of CSS tweaks and re-writes of goget.js and index.html. Also, I had to throw handlebars back in there.

Thirdly, I deployed it. It doesn't run under HTTPS yet, so don't put in anything illegal or embarrassing, but that's a usable shopping list synchronizer which I intend to use. Let me know if you try it and anything explodes.

At the moment, I've got the jQuery and Angular versions separated into different branches, but I'll merge them shortly and just provide each as a separate front-end|2|. On a scale this small, it turns out not to matter much how you write the interface. If you check out the line-count on both those front-ends, the reactive version saves about 10 lines of HTML and 15 of JavaScript. It stacks up in larger applications, and if there's an option to use less JS, I'll take it, but in this case, the elegant solution doesn't work, so whatever. Lets start with the HTML markup first. Here's the Angular

There's a bunch of common boilerplate at the bottom and top that you can safely ignore. The meat begins at the body tag and stops at the block comment denoting the Styles section. The only real difference is that you can see some unfamiliar util calls and explicit templates in the jQuery version. Oh, the Angular version also controls its visibility explicitly through those ng-show attributes; the jQuery version relies on CSS to do the same. The actual differences are readily on display in the JS code though. First, Angular

So, in other words, there are three controls in the DOM somewhere, and I'd like to grab their values and pass them to the function goget.add. I could call goget.add($(".controls .name").val(), $(".controls .comment").val(), $(".controls .count").val(),), but that seems more than mildly annoying if I have to do it multiple times. So I pulled out the pattern; applyToVals takes a function, a DOM context|3| and a list of element selectors. It then concatenates the DOM context onto each of the selectors, and returns a list of the values of the elements specified by those selectors.

That's actually a snippet from the Angular-style HTML file, and only about 1/5th of it is responsible for the equivalent. Each of the inputs we care about has an ng-model property, and that we then just pass those models into add. If it worked where I needed it to, I wouldn't have bothered finding a better solution than this.

Most of the rest of the util namespace is actually just intermediate definitions for util.applyToVals, and there's one definition that uses it specifically to pull out data from the user form. Oh, and a shorthand for compiling a particular Handlebars template. There's a snippet where we define a helper function for the main template, and a place in the goget namespace wherein we call render, which is famously missing from Angular, and that's really it. The rest of it is transliterated pretty clearly.

The only other thing I'll highlight is that the Angular version contains this:

which the jQuery version doesn't. As far as I'm concerned, this is the one place where the Angular devs are just plain wrong. I know other approaches are possible here, so I guess it's a good thing that there's an option. But as far as I'm aware, all the widely used HTTP servers out there right now expect POST parameters to be encoded in the www-form format by default. And that's not what Angular does with JSON objects by default.

$http.post("/foo", { bar: 1, baz: 2 });

will actually send the server a POST body that looks like {"bar":1,"baz":2}. At that point it's up to you to grab the raw request and parse that body with a JSON interpreter. What you likely want, because most HTTP servers will parse it appropriately by default, is bar=1&baz=2, with both the keys and values getting URI-encoded just in case. The way you do that is by using this config option I've got above. The jQuery equivalent doesn't need this, because $.post does the right thing with no additional prodding|4|.

1 - |back| - Specifically, it had to do with reading the count parameter. You can see the fix here and here. Short version: count needs to be readable as an Integer for the back-end to proceed, but it's coming from the outside, which means I can't guarantee that. The initial version of the code was optimistic, simply using read :: Integer assuming it could work. If a malicious front-end sent back something that couldn't be read as a number, that would have given me a run-time error. I'm under the impression that these are to be avoided in Haskell..

2 - |back| - Defaulting to jQuery because I want to use it from my phone, and putting the angular version at /angular/* rather than at root.

3 - |back| - The common selector prefix of any elements I'll need to grab from.

4 - |back| - I have no idea whether there are options to do it another way in jQuery.