So far, I've covered what I want in a JavaScript Framework and then I covered several popular JavaScript frameworks and why none of them are what I want.
Just when I was about to despair, however, I ran across a little-regarded framework that does just what I want.
Just to rehash quickly, here are my criteria:
Last time, I covered what I want from a JavaScript framework (and a bit about why). I don't want to rehash all of that (you could read the entry if you cared), but let's start with the table of what I want from the end of the previous entry.
Over the course of a few years, I gradually let my JavaScript skills atrophy. My programming partner had more interest in it than I did and so it seemed more efficient to have him do more JavaScript work than I did. That, of course, led to him becoming more efficient at it. A reinforcing cycle quickly ensued.
A little over a year ago, I realized that the pattern had gone too far and decided I needed to slowly start doing a bit more and build those muscles back.
As I have been regaining those skills, I've noticed that our JavaScript is less organized than I would like.
In my last post about page controllers, Jason Holden asked on which pages I use page controllers. This is a great question and speaks to a larger issue of code organization that applies to CSS and JavaScript as well.
While working on a form that makes use of some simple AJAX, I discovered that using a Page Controller can make this easier - especially when combined with JSMX.
I try to avoid blog posts that just repeat what has been said elsewhere, but this is really nice.
I blogged earlier (mid-2005) about a JavaScript version of cfdump. I actually used this recently to help me implement JSMX (which I love!).
I saw an entry today the strikefish blog about another JavaScript CFDUMP which looks great. The advantage of this one is that the output more closely matches the output and behavior of cfdump. I like this in part because the format is familiar and in part because it is a really useful format.
If you just want to see the tool, take a look at JavaScript Dump.
I just found an interesting article by Pete Forde arguing against the "next" button and paging through records entirely.
He even points to an example or two of how this could be done.
His point is basically that since the web is non-linear, pages don't make sense. After all, the contents of "page 2" today won't necessarily match the contents of "page 2" tomorrow.
Today I was working on some AJAX code and realized that I would rather get my data from a CFC than from XML data. A few minutes of research later and I have JSMX up and running.
I already had a CFC with the method I needed to get my data with access="remote" (hopefully more on why I have this later - a new approach that seems promising). I thought it would be nice to add another remote method to generate the XML I needed for my AJAX.
This turned out to be rather easy, but I had to set returntype="void" and output="yes" and output the XML straight to the CFC page. This worked, but seemed a bit "hacky".
I was sure that someone had thought of a better way, so off to Google I went to find it.
JSMX advertises itself as an AJAX API - which it is (actually it advertises itself as "The Universal AJAX API"). It has some distinct advantages over other AJAX APIs that I have looked at (and never used). For one, it is just one 13K JS file. For another, it can easily digest data in a number of formats.
Notably, it can digest WDDX data. This is significant because that is the format of data you get if you do an HTTP "Get" on a remote method in a CFC.
The site has a few good examples of use , but none on WDDX. I was unable to find out how it structured the WDDX data in JavaScript. Fortunately, DP_Debug came to the rescue. This is basically cfdump for JavaScript - very handy.
I used the following syntax to test the results:
<script type="text/javascript">
http('GET', 'mycomp.cfc?method=mymethod', DP_Debug.dump);
DP_Debug.dump(MyObject)
</script>
This revealed that the results are basically identical to what you would get if you used <cfwddx> with action="CFML2JS". This made the JavaScript to digest the data even easier than it was to digest the XML.
My steps to implement JSMX:
The result is that my JavaScript got smaller and easier to use and I was able to remove the file to serve up XML data and rely on the CFC to provide that data.
My only complaint about JSMX so far is that it could be much smaller than 13K if the comments and white-space were removed. Other than that small complaint, it is a thing of beauty!
cfdump is such a handy utility in ColdFusion. I have always wanted a similar utility for JavaScript. Now there is one!
I thought of trying to write such a utility myself, but the task seemed, well, daunting. Fortuntately, Depressed Press of Boston has tackled the project that I never would have done myself. I haven't used it yet, but I very much look forward to it.
For those of you that aren't familiar with cfdump, it outputs the contents of a simple or complex ColdFusion variable, similarly, dpDump() output the contents of a simple of complex JavaScript variable. I imagine that this will come in very handy during debugging.
Read about dpDump().
Thanks Depressed Press of Boston!
Over time I have found a handful of nifty little JavaScript utilities. I was about to compile a handy reference of them for myself when I realized that others might be interested in them as well.
These are scripts that I have used and liked as well as some scripts that I haven't used book look nifty.
Here they are in no order:
General
