Ian Bicking: the old part of his blog

Repetition Javascript Library

Imaginary Landscape open-sourced some work I did recently on a Javascript library for handling repeating elements in forms. I've rewritten it more than once since then, and might just rewrite it again before it settles down.

After the last rewrite it more-or-less follows the WHAT-WG Web Forms 2.0 spec with respect to repeating forms. The implementation practically falls out of the spec, so after I just read it closely it was pretty clear how to implement it. Though, having implemented it, I need to bring some questions back to the WHAT-WG group -- especially related to moving repetition blocks around.

Conveniently, the spec works very well with FormEncode and variabledecode in particular. But it's actually expedience that made me implement it in the first place. Without repeating form elements, you have to have multiple complex forms, with lots of add/edit/delete functionality. With repeating forms you just have a single form, and the update is a single HTTP request. Less templates, less things to explain, less controllers, and a better user experience to boot.

I still have to figure out where this will go. I like MochiKit, but I've ended up factoring out nearly all the MochiKit dependencies (not because I was trying, it just happened). And it also fits a somewhat different style -- the Javascript is largely implicit, based on declarative HTML as defined in the spec. A big feature of the Web Forms 2.0 spec (IMHO) is that it isn't expressed in Javascript, and you don't have to think about Javascript while using it.

OTOH, I have no desire to set up a separate project or deal with any of that. I'd much rather glom onto someone else's project ;)

I've seen other implementations of portions of WHAT-WG. But they all seem complicated, or tied to one browser. (Well, I haven't tested on IE yet, but that's incidental.) That seems unnecessary, because at least large portions of Web Forms 2.0 is pretty simple Javascript. Plus I have a hard time finding them.

Anyway, the files are temporarily located at http://svn.colorstudy.com/home/ianb/repeat_form and a demo at https://ianbicking.org/examples/repeat_form/form.html

Created 27 Oct '05

Comments:

hi ian,

fyi, I just tried out your demo page and it doesn't work at all in ie. Not sure if you're aware of this, so I thought I'd point it out :).

# dan

Indeed; I just fixed some of the most obvious problems. It seems that IE returns properties as Attributes, including bound functions. Also there's no .hasAttribute() method. I'm still crashing IE when I add multiple moons, I'll have to look into that some more. Some sort of loop problem, I'm guessing.

# Ian Bicking

This looks pretty interesting.

One thing I didn't quite get about this spec was : how do you work out reordering on the serverside? Do they expect the order in the POST or query string to be preserved/examined?

Maybe it needs an event so it is possible to twiddle with a hidden field on reorder or something.

# rjwittams

The spec does specify events, which this library doesn't do -- I don't understand Javascript events that much at the moment. I actually followed this post up with a post to the whatwg list where I mention this problem. Hopefully some resolution will come up for this; though as I was writing it occurred to me that it's not too hard to fix by putting in a field like this in the template:

<div repeat="template" id="foo">
  <input type="hidden" name="foo-order" value="[foo]">
  ...
</div>

Then foo-order will contain an ordered list of the indexes -- the spec specifically indicates that all attributes are substituted, not just input names. So if you don't think of index as representing order -- just some relatedness -- it's not so bad. I think this is a reasonable way to handle it, the more I think about it, and it's definitely something I can add to variable_decode (so it orders the lists for you).

# Ian Bicking

Hey Ian:

Javascript is not just for web. MochiKit has some real potential for things like string formatting functions.

Does your work have some generic usefullness, as well. I mean usefull for things outside of the web world, also.

# Brian Ray

This library? No, I don't think so -- it's very closely tied to the DOM, and HTML forms. I suspect XForms already has functionality like this built into the spec. This just happens to work today, unlike XForms. I have no idea what Flash programming is like, but I assume they also don't have something similar enough to the DOM for this to matter.

# Ian Bicking

Well... I really did not expect this library to be useful in this context. However, I guess what I am really wishing for is some general usable runtime functions used to create these javascript things. You see, Javascript is now showing up everywhere. It's easy to embed SpiderMonkey or WebKit's version... And there does not seem to be many libraries out there which help in doing basic operations. Instead, Javascript coders keep rewriting the same code over and over. When I saw MochiKit I had/have high hopes of abstracting out the generally usefull methods. Likewise, it would be helpful if the Repetition Javasript library used some abstraction between the web stuff which I do not know and some generally usefull Javascript methods.

I would be happy to find more MochiKit like stuff out there but have not have had the time to look and unsure if any exists of this quality.

On the other hand, can't everything just be written in Python.

# Brian Ray

MochiKit could certainly be used in those other contexts; the only difficulty might be the packaging and loading system, which is quirky in Javascript, and what tools that do exist are usually tied closely to their environment, e.g., a web browser. But MochiKit's things like iteration, adaptation, comparisons, etc., are all core Javascript things with no relation to the web.

# Ian Bicking

MochiKit will eventually end up getting refactored and tested such that it works in some non-browser environments, but that's not an immediate plan of mine -- unless I end up writing Yet Another Goddamned JavaScript Unit-Testing Library.

Test.Simple is OK, but the implementation is ugly, non-portable, and could behave better in Safari. I could do better, but I really need to look at what Dojo is doing first as they also have their own unit test library.