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.
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 ;)
Anyway, the files are temporarily located at http://svn.colorstudy.com/home/ianb/repeat_form and a demo at http://ianbicking.org/examples/repeat_form/form.html
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.
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.
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).
Does your work have some generic usefullness, as well. I mean usefull for things outside of the web world, also.
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.
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.
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.