Last night I came up with a grand plan to create a JS HTML serializer so I could create JSON representations of HTML markup. My goal was to completely do away with creating HTML markup via DOM or string building, relying instead on standardized JSON formatted objects and some parser functions to convert them to and from HTML.

Well, turns out it’s already done – at least in the abstract. Rats. All my good ideas are other people’s.
http://jsonml.org/

I’m going to do a little more digging, but a Prototype/jQuery extension to generate HTML markup based on that format seems like a real no-brainer. It could seriously reduce code clutter, plus it would abstract away the actual node creation into a library that could handle it in a way that’s most efficient for the JS framework being used.

IBM wrote an article on it way back in July 2007, which is worth a read:
http://www.ibm.com/developerworks/library/x-jsonml/

Neat stuff! I’ll certainly investigate it for future DHTML work.

Kevin Yank of Sitepoint.com posted this interesting (and rather scathing) article on Google Closure, outlining some inefficiencies in their code, and how it seems to have been written by Java developers. Extremely interesting stuff, he makes some really good points.

Google Closure – in case you missed the announcement – is an open-source JS library a la Prototype, Mootools and jQuery. Still haven’t figured out why on EARTH they called it “closure”…. How confusing is that?

But the project itself is well worth investigating.

Hey all,

Last weekend, having semi-recovered from the flu, I released a Form Tools core update that includes a new feature: Client Map filters. Now, when you go to your Edit View -> Filters tab, you’ll notice a few changes.

The old filters have been renamed to “Standard Filters” and there’s a new section underneath labeled “Client Map Filters”. What this new filter type does is let you map the contents of a form field to the values of a client account. So you can now have a single View that shows different information to a client based on whatever values that client has in their user account settings. It’s recommended that you use it in conjunction with the Extended Client Fields module to add custom, “meta” information to client accounts that can’t be seen or edited by the clients.

I’ve documented the feature here. It’s not quite finished, but hopefully it’ll provide enough information for users to use the feature until I have time to finish writing it up.

The Grand Plan

Now that that feature is done, I have one more smaller project to complete (Submission Accounts module update) and then back to “Big Picture” stuff. There’s two things of immediate concern:

1. This Christmas I have a week booked off work so I’m going to update the Form Tools site to archive the old Form Tools 1 content & forum and move ft2.formtools.org to www.formtools.org. Form Tools 1 will still be available for download and I’ll keep the forums open.

2. Language file update. This is long overdue: the mechanism for releasing Form Tools builds is pretty neat, if I say so myself – it’s all automated and integrated with SVN and by and large has saved me weeks and weeks of unnecessary work. However, the language files are still not fully integrated with this process. Namely, whenever a new version includes a change to the language file content, Open Translate (which handles the translations) isn’t notified. The upshot of this is that the language files keep getting slightly out of date. No good!

So I’m going to figure out a way to force communication with Open Translate to update content.

Other than that there are several other language-file-related issues that need squashing.

Once all THAT’s done, I can get back to the fun stuff: module development! I’m thinking an akismet module to tackle the problem of form spam head on…

- Ben

http://icant.co.uk/sandbox/eventdelegation/

“Event Delegation” is a technique to get around manually assigning event handlers to multiple, similar elements – e.g. rows in a table or list items. You just assign a single event handler to the parent element, then rely on the browser’s built-in event bubbling to trigger the handler. All you need to do is extract the original target (i.e. the original element that the event occurred upon) to do whatever you will. As Douglas Crockford has mentioned somewhere, this lends weight to the superiority of the bubbling model over the capturing model in that it allows for a form of event inheritance in the browser.

For large content, it can significantly speed up the page significantly and reduce the overall number of bound handlers.

Very cool. I’m going to have to implement this for some Form Tools pages.