We all know JQuery is awesome right? That should be common knowledge by now. But, if you have ever created an app that makes use of several of the fantastic plugins available for JQuery, then you are going to end up with multiple tags for JQuery alone...not to mention any of your own external javascript files.

So, why is this a problem?

First of all, there is a little bit of bloat going on in this scenario. One could easily end up with over 200Kb of javascript in an assortment of these files. The other thing to consider is that the browser can only make so many concurrent connections to the web server (each external javascript file is one connection by the way) so add all of these files, a bunch of images, a couple .css files and we are making that user wait longer than really necessary.

Lets reduce the number of browser - to - server connections.

That seems easy enough. Instead of multiple external script calls:

<script type="text/javascript" src="/js/jquery/jquery.js"></script>
<script type="text/javascript" src="/js/jquery/jquery.form.js"></script>
<script type="text/javascript" src="/js/jquery/jquery.jqModal.js"></script>
<script type="text/javascript" src="/js/jquery/jquery.history_remote.pack.js"></script>

We could combine them all into one big javascript file and reference it:

<script type="text/javascript" src="/js/myBigScript.js"></script>

Well what happens when you want to make a change to one of the source js files? Or you need to change the order of how the files are included? Or maybe the javascript files needed vary based off of where you are in your app and you don't want to include ALL of the files every time? Thats where I think I can help...

I have just recently (as in today) finished up a custom tag to do just that. For lack of a better name I called it <cf_scriptalizer> Here is an example use of the custom tag.

<cf_scriptalizer 
	filePrefix="myscript"
		
	scriptalizerDirectory="/js" 
	
	scriptFileList="
		/js/jquery/jqModal.js,
		/js/jquery/jquery.js,
		/js/jquery/jquery.MultiFile.js,
		/js/jquery/jquery.blockUI.js,
		/js/jquery/jquery.corner.js,
		/js/jquery/jquery.form.js,
		/js/jquery/jquery.history_remote.pack.js,
		/js/jquery/jquery-dom.js
		"

	reload="true"
	>

• filePrefix (optional): prefix of the generated javascript file. "scriptalizer" by default
• scriptalizerDirectory: relative path to the desired output location
• scriptFileList: list of js files in the order you would include them
• reload (optional) - scriptalizer will inspect each js file for changes made since last access

More about reload: When/if you pass reload=true, <cf_scriptalizer> will inspect each of the source javascript files and if a change is detected, regenerate the combined javascript file.

Now that we have reduced the number of connections for external javascript files down to just one for this request, what can we do about reducing the size.

<cf_scriptalizer> takes an additional optional attribute of "minifierObject" as seen in the example below:

<cfset minifier = CreateObject("component","com.cfyuiminifier.cfYUIMinifier").init(path="/com/cfyuiminifier")/>

<cf_scriptalizer 
	filePrefix="myscript"
	scriptalizerDirectory="/js" 
	scriptFileList="
		/js/jquery/jqModal.js,
		/js/jquery/jquery.js,
		/js/jquery/jquery.MultiFile.js,
		/js/jquery/jquery.blockUI.js,
		/js/jquery/jquery.corner.js,
		/js/jquery/jquery.form.js,
		/js/jquery/jquery.history_remote.pack.js,
		/js/jquery/jquery-dom.js
		"
	minifierObject = #minifier#	
	reload="true"
	>

As you can see, I am passing in the object "minifier" that contains the method minify() that accepts a string of all of the comibined javascript and returns a string of the minified javascript.

This additional component was abstracted from the custom tag itself just in case the user has some issue with YUICompressor or wants to implement his/her own solution to compress/clean/minify/etc the source javascript.

In this example, the combined jquery files resulted in a 123.1 KB javascript file (pre-minification). But, once cfyuiminifier.minify() was run on the source, we ended up with a combined javascript file that was only 79.7 KB!

CAVEATS:

I have not yet run this on any live sites.

This is brand new code from my scribble pad, so please be aware you may encounter some bugs!

This was developed on my Linux machine and haven't tested it anywhere outside of this environment.

DOWNLOADS:

If anybody has any specific requests for features, or would like to contribute please let me know. I wrote this in an attempt solve a specfic need for some applications I have been working on, and ended up with something I thought might be beneficial to others. Please report back with any successes (or failures) with this tool...I am very interested in hearing about your experience(s).

Ok, so I need to get something off my chest. Reading Peter Bell (and now that I finally met him in person, listening to him) makes me feel a little dumb sometimes. I can clearly understand that he is speaking English, but sometimes it feels that I must have just skipped that day in word-learning class.

I have been intrigued by his application generation topics since he first started blogging just over a year ago, and until recently it was more of a mystical fantasy world that only Peter Bell had access to. Now, hopefully I am not too far off target in my understanding but I think things are beginning to sink in and light bulbs are beginning to click on in my head.

DSLs
Domain Specific Language? What the heck?! Just when I thought I was getting a handle on more advanced topics in CF, people (not just Peter by the way) have to start kicking this one around. The way I understand it, DSLs are a way to describe, lets say, your model. In other words, we should be able to describe the objects in our system without introducing the specifics of how this code will look in whatever language your application is generated in (ha! I am talking about generating applications).

Basically this concepts aids in  separating What you mean, from how you say it. 

For example: Lets say we want a Person object, and for this example I will use XML to write the DSL.
    <objects>
        <object  name=”Person”>
            <attributes>
                <attribute name=”FirstName”>
                    <length value = “50”/>
                    <type value = “varchar”/>
                    <default value = “”/>
                </attribute>
                <attribute name=”LastName”>
                    <length value = “50”/>
                    <type value =  “varchar”/>
                    <default value =  “”/>
                </attribute>
                <attribute name=”DateTimeUpdated”>
                    <length value =  “”/>
                    <type value =  “datetime”/>
                    <default value =  “Now”/>
                </attribute>
            </attributes>
            <relationships>
                <relationship name=”Group”>
                    <type value =  ”OneToMany”/>
                    <key value =  “GroupId”/>
                </relationship>
            </relationships>
        </object>
    </objects>

Now, obviously this is very simple and just written on the fly (literally...I am on an airplane right now), but it should show that we are describing things about this Person object without saying anything about a programming language that will eventually be used.
This example might look slightly familiar if you have used any of the ORM frameworks, that is because their configuration files are a good example of a DSL.

So, Ok I have an XML document that details every last object in my system, so what? Well, one thing that I know I lose sight of is that there are other programming languages out there in this world (or so I've heard) and we may want to document our model language agnostic, so that if we ever need to generate this application in some other, more inferior, language we could.

Two things that this application generator are going to do is:

1. Create the model - in our case the bean, DAO, gateway, service. In my case, it would be all CFC's, but what if you wanted Ruby or .Net or ____.
2. Generate database creation scripts. Another good example of why we want to create generic documentation about our objects. We will need to create different db scripts based on the DBRMS of our choice.

Hopefully I am not dumbing this down too much, but I am positive I am still missing some of the major concepts that Peter Bell has been laying down on this topic. But I think the general idea, is that we create this meta-data about our objects and then use that information to generate code/db scripts/etc using our “Translators” “Generators” etc for our specific needs or language.

So, to extend just our basic model, table creation concepts. Lets say we now need to document functionality in a way that avoids being language specific.

Maybe as part of our object definitions we might have a functions node:
    <object name=”Person”>
        <attributes>
            <attribute /> 
        </attributes>
        <methods>
            <method name=”Authenticate”>
                <validate attribute=”Firstname”/>
                <validate attribute=”LastName”/>
            </method>
        </methods>
    </object>

 
(Obviously we probably wouldn't need a way to authenticate a Person by their first and last name, but I just stayed with the same object we talked about above. )

So, in this case could assume that we translate this new optional method node and create a method in our PersonService.cfc perhaps called “AuthenticatePerson” or maybe just “Authenticate” whatever. If you decide to read up on Peter's stuff on extending a Base class, we could use a generic method called “authenticate” and since we are passing in the things to validate against, it would be easy to create a generic Authenticate method.

If you want to find out more on this topic, be sure to check out Peter Bell's Blog on Application Generation.

Here at the day job we have a very large mortgage loan application form that, now that we have rewritten it, makes AJAX calls to the bean onChange of each field.

These calls are made asynchronously, which means the user really has no idea that the post is being performed. (unless they happen to be watching their firebug console) But, if they ever decided to log out, click on some other link, close their tab, etc...any data being posted at that time could (and probably would) be lost forever.

The challenge: Make sure the users don't leave the page, or submit the application mid AJAX post.

Now, there is no real way to lock a user to the computer and make them wait until the saves are completed. But we can monitor the state of the AJAX request and, based off of that, decide whether or not to alert the user that they shouldn't leave the page.

The solution: (well part of it anyways) window.onbeforeunload

Now, as part of the AJAX call we monitor the readystate and look for a '4' value. A value of 4 represents a completed request. (here are the readyState status codes)

As we monitor the readyState and watch for that '4', we flag a variable I called 'completionIndicator'. False on the initial AJAX request, set to True ones a readyState of 4 is returned.

Now that we know whats going on with AJAX, we can decide whether or not to "lock" the user to the form. What I came up with was the use of window.onbeforeunload which is used to execute statements whenever the user exits the document.

So, anytime the users tries to exit the document, we run a method I called checkProgressState(). There I conditionally return a message to window.onbeforeunload. If nothing is returned, no message (confirmation window) will be displayed.

You will notice I am return a string in that call. If you return a message to window.onbeforeunload it will insert the text between to two default messages on the confirmation box.

All done right?... Um, no. Now we have to deal with Internet Explorer. (dear bill gates, please stop making my job harder)

Our super cool AJAX'y mortgage loan application form is a super huge form. All said and done there are now 9 tabs full of questions which we swap in and out all client-side, cool right? Not if you ask Mr. Gates.

Each of our tabs has an anchor tag which fires a few routines onclick to swap out the current content, with the desired tab's form content. And luckily for me, IE (both 6 and 7) treated that as a page exit and would thus fire the window.onbeforeunload stuff I had working so sweetly in Firefox.

Hey, I like challenges: What can we do to stop IE from being so IE about this?

In order to stop IE from running my "Are you sure you want to leave.?!" stuff each tab click, I had to flag a new variable that would allow me to turn on and off the function from above. So onclick of a tab, we set a new variable I called 'checkProgressFlag' to FALSE, then once my new tab/content were done swapping, set the value back to TRUE.

Now all of our users filling out the application will at least be warned about why they shouldn't leave just quite yet.