I had been recently working through the training videos and associated labs to get my TCAD certification (which I completed thanks to some free takes associated with the Titanium 2.0 release) and found that one of the little things I had done in my local data lab was pretty nice, and I thought worth sharing. Most languages have ways of being able to execute common code or setting things up--with Java you’ve got Aspects or Injection--but the problem is that you’ve got to add additional technologies to your stack to make things really work. One of the nice things about JavaScript is that the language is so flexible and amazingly robust right out of the box—one of these features is the ability to wrap functions.
In the lab I mentioned, you need to implement operations against a SQLite database and make sure you aren’t leaving open connections, so you want to open and close the database connections every time. Now, I could just add those 2 lines to every function--it’s not like it’s much--but I’d rather not. So I created the following:
Basically, what I’m doing here is defining a function that takes in another function--it will open the database (which is being assigned to a module level variable), make sure the table we are looking for exists (the only table in the application at this time) and then calls the passed in function. Upon return it will close the database and return what was returned by the other function. Very simple, very clean. An example usage is as follows:
Here all we see is that we run our command to insert the fugitive into the system is merely the SQL statement to do the task (and a logging statement). Easy as pie and everything is open and closed as necessary. We create the function as the parameter into the other function and we get back a function that has been wrapped to automatically open and close the db. Pretty nice huh?
As you might note, my function returned above has the 1 parameter defined instead of allowing to take in whatever and pass that along to the function parameter. This is more just a function of my initial lackadaisical approach--since this was just a lab I wasn’t interested in looking up that syntax (I haven’t had the pleasure of using it myself as of yet). However this is perfectly possible with JavaScript. Also, when I have more than 1 table to worry about that that table creation statement will get moved elsewhere. I don’t know if this can really be dubbed a “best practice” but I do think it is mighty nifty in the least, and saves on reused code.
If you’re interested, I’ve got my lab exercise code on git hub and the full DAO can be found here—all with the aforementioned disclaimer that these artifacts are categorically works in progress/trial and error style lab exercises. I’m doing my best to “practice good practices” but learning on my own in a silo leaves some things to be desired—sharing what I am learning and hearing from others is a great way to keep the knowledge flowing. I welcome your feedback!
-Adam Swift, 5AM Solutions
Note: This post appeared originally at Adam's blog, Caffeinated Coding.
