Ah! ’bout time! Now you can add your own menu items to the context navigation menu in Chrome (when you right-click on the page).
http://blog.chromium.org/2010/08/new-in-google-chrome-beta-more.html
This will be SODDING handy.
Entomology!
FINALLY, I enrolled in a course on Entomology at Iowa State – ENT 201. Insects are something which has interested me for longer than I can remember – and a subject of which I’ve comparatively little. I’ve probably been interested in it as far back as when I as in diapers and ate one, thinking that it tasted “okay, considering”.
It’s a 5-week course. This is going to suck up some of my time otherwise spent on Form Tools and generatedata.com, but what the hell – it looks fun. :)
Just a heads up.
Form Tools tutorial: checking for uniqueness
I just completed a rather handy tutorial for Form Tools users.
It checks incoming form submissions to ensure that the incoming information hasn’t already been added in the database. This lets you ensure that multiple submissions don’t get registered with the same email address or username, for example. The actual criteria for uniqueness is entirely dependent on the form content.
http://docs.formtools.org/tutorials/checking_for_uniqueness/
IE9 Preview
A recent discussion of IE9 from the IE Blog.
From a JS point of view, what I find most exciting is that the new JS engine is embedded directly within the browser and can interact with the DOM “natively” (i.e. not through an API). Functionally, JS will work exactly the same way (of course), except that a lot of the bottlenecks that we get for interacting with the DOM will be lifted. Too cool.
Queuing expensive DOM changes (avoiding timing problems with JS)
This is a re-write of an old post, written back in 2007. I recently re-used this code in another script and it’s as useful today as it was then. Plus I understand it a little better now, so I thought it was time to re-discuss it.
As any client-side web developer knows, DOM scripting is inherently slow. Accessing and manipulating the DOM requires the browser’s javascript engine to interface with the DOM API – which in of itself is slow: any time you have two fundamentally different components talking to one another via an interface you’re going to get a bit of a bottleneck. But also, accessing and especially changing the contents of the DOM can cause reflows (the re-creation of the internal representation of the visible page within the browser) and repaints (the actual re-rendering of the visible web page to the user). And this is slow!
So what of it?
Well, here’s a common scenario. Try dynamically inserting a large block of HTML into your page, then immediately accessing an element within it. Does it work? Well… sometimes it may, sometimes it may not – it can depend on the quality of the browser, how busy the CPU is, the OS, the volume of HTML inserted – a whole range of factors. From a coding standpoint (and this is what *I* find interesting!), it looks fine: on one line you insert the content, on the next you access it. What could be wrong with that? Well, this is one of those baaaad instances where you need to have an understanding of what’s going on within the browser. You shouldn’t, but you do.
So here’s how to get around it. The following code lets you queue your DOM changes. It only proceeds to the next item in the queue when a custom assertion (e.g. “does element X exist?”) is confirmed. This can ensure that regardless of browser, environment, etc. your code will execute in a sequential manner where in every step you can rely on the DOM containing the content that you expect.
The code
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 | var $Q = { // each index should be an array with two indexes, both functions: // 0: the code to execute // 1: boolean test to determine completion queue: [], run: function() { if (!$Q.queue.length) return; // if this code hasn't begun being executed, start 'er up if (!$Q.queue[0][2]) { $Q.queue[0][0](); $Q.queue[0][2] = window.setInterval("$Q.process()", 50); } }, process: function() { if ($Q.queue[0][1]()) { window.clearInterval($Q.queue[0][2]); $Q.queue.shift(); $Q.run(); } } } |
Usage
It works very simply. Any time you have something that could take up lots of time, just add it to the queue. When you’re ready to run that code, just run() it.
1 2 3 4 5 6 7 8 9 10 11 12 | $Q.push([ function() { // do expensive stuff here... }, function () { // do our test here and stash it in $boolean ... return $boolean; } ]); $Q.run(); |
Form Tools: Client Audit Module
I’ve just finished the first version of a new module for Form Tools, written specifically for a client. Not sure if I’m allowed to say who it is (I suspect not), so I’ll just say that it’s one of the largest companies in the world. Very cool that they’re using Form Tools.
The Client Audit module provides Form Tools administrators with a way to track key events / actions that occur on client accounts, such as when the clients accounts are logging in and out, when they’re updated and what permission changes occur and at what time. This, coupled with a very simple but powerful search tool, provides an invaluable tool for security and auditing purposes.
Read more about the module here:
http://modules.formtools.org/client_audit/
Script Updates
generatedata.com 2.3.8 beta
– Now offers country-specific data for Belgium. Thanks to Kob in the generatedata forums for providing the data!
– the SQL export type now includes a “DROP TABLE†option
See: http://beta.generatedata.com
Form Tools 2.0.3 beta
The main focus on this release is security. 2.0.3 adds the following security options for client passwords (all of these features are disabled by default).
1. Control over the password content: minimum length, must contain upper case char, must contain number, must contain ~!@#$%^&.
2. Password history: prevents you from re-using a recent password
3. Auto-disable an account after an unbroken sequence of unsuccessful login attempts. You can choose the number (between 3 and 10).
Recent Comments