I took a picture of the Liberty Bell earlier, but it was a mere formality: the bell, in real life, was smaller, duller, and much less impressive than I realized. Congress Hall, too, was neat but tidily boring. I thought of the Nick Cage vehicle filmed in next-door Independence Hall and can’t help but think it’s all been trivialized to the point where it’s impossible to care.

History, for a block

I’m here for Sungard HE’s annual Summit, an international get-together for users of Sungard’s ERP system, Banner. Last year, I blogged from Anaheim, and there were about 8,000 attendees; this year, there’s perhaps 5,500, a significant decrease. One could argue that it’s due to restricted travel budgets from the current economic crisis; I, cynically, will point out that nobody gives a shit about the Liberty Bell compared to, say, Disneyland.

If you ask me, of course, Disneyland is a blight upon the pristine Californian landscape, but I hope we can all agree on the historical import of Philadelphia. It did, for instance, house the entire federal government for 10 years (1790-1800); it was the most populous city in the nation at that time, which didn’t help when Yellow Fever killed a third of its inhabitants. Though one of several critical locations in the history of the country, however, Philadelphia takes a decidedly low-key approach to publicizing it.

When I went to Springfield in the fall of ’08, I couldn’t throw a rock without hitting a brown landmark sign; half the city’s restaurants or tourist attractions invoke Lincoln or the government. In other words, the city really milked the Springfield/Lincoln connection for all it was worth; Philadelphia, on the other hand, while it doesn’t fail to mention its historicity, cordons off the Liberty Bell and Congress/Independence Halls appropriately, but has them sitting in the middle of urban sprawl. One moment, I’m passing the 6th pawn shop in as many blocks on the Market St.; the next, I’m suddenly standing before a 200+ year old brick edifice that housed some of the greatest political thinkers in history. Disinterested guards (with pistols!) watch the exits. Within line-of-sight, a homeless man curls against an office building, wrapped in a flowery blanket, sleeping despite the chilly breeze and the 2-o’clock sunlight.

I did see the Liberty Bell in person, but somehow it failed to move me: the build-up included a long hallway full of tasteful displays which illustrated the Bell’s historical and political importance. Then it was there, at the end of the hall, cordoned off with a metal bar. It was smaller than I thought, its inscription blurry from the distance and the flash of cameras. Somehow, it was larger (literally and metaphorically) in my mind than it seemed to be in person.

OK, but brotherly love?

Perhaps I’m just conflicted. I came here for the Banner conference, and can’t help but feel melancholy when I think that, had he not died, my father might well be here. In an alternate history, I could have just come back from sharing a beer with him at the Irish pub, shooting the shit about degree audits or portal design. He and I would have had the sort of casual male relationships that fathers are eventually supposed to have with their sons, fraternal and yet deeply symbolic.

But my dad and I never had too many heart-to-hearts; he was never the maudlin type, and he preferred treating his sons like friends and colleagues rather than children (once we were old enough, of course). I know that he was—to my occasional embarrassment—a reader of this blog. But he only ever left one comment… last year, when I blogged about the 2008 Summit. So, I suppose, my attendance this year is a constant reminder of what should have been in a just world. Dad was the figurative strawberry field, and Disney bulldozed him to erect its latest ride. I’ll never know why he elected to comment upon that entry and none other. I could posit that he was feeling alienated in his new job, in need of communication with his son(s). I could argue that he circumstantially felt compelled to comment upon the strength of my writing (sure!) and perhaps some emotional resonance (slightly more plausible). His single solitary comment has remained immortalized to me as a reminder of something innately human and youthful about my dad… that he—against perhaps all my expectations—showed up in a medium totally foreign to him, in order to communicate with me. That he may have felt too embarrassed to talk this way with me in real life is no surprise—ask me sometime about my “birds & bees” talk—but it still remains a focal point in my memory of him.

Philadelphia, in many ways like my father, seems determined to conflict and confuse me. Its downtown area is a nice grid—except in the part where I’m staying and traveling, which devolves into curves and circles. Though I arrived yesterday (Saturday, March 21st), I have yet to do anything in Summit-related as of today (Sunday, March 22): the only sessions today were of the useless “Banner! Whoo!” variety, which I swore after last year I would no longer attend. Tomorrow starts the meat and potatoes of the conference, 2.5 days of solid sessions, though those sessions’ usefulness has yet to be determined.

I spent today sightseeing. I ate lunch at the Down Home Diner, a small greasy spoon in the Reading Terminal Market (a strange name for an indoor marketplace, selling just about everything). I had a bacon cheeseburger with bacon slices that were—I kid you not— a quarter of an inch thick. I was so positively ecstatic about pork as a result that I made an impulse purchase of an “I ♥ Bacon” t-shirt; a cheese-steak is pending, since I don’t think that TSA employees let you fly out unless you can prove you’ve eaten one.

Just like last year, I’ve gotten excessively introspective and maudlin. New places will do that to me, especially places that make me walk around with my eyes upward and my mouth slightly agape. Philadelphia, for all its (very obvious) faults, is an incomprehensible city, confusing as it is large. Its apparent insouciance toward its own history serves only to beleaguer the enthusiastic tourist, who is earnest until five beers in (then belligerent or solemn, depending on the tourist).

The conference, too, seems to some degree insouciant, as though it is merely going through the motions this year. From 8’000 attendees (Anaheim + Disneyland) to 5’500 (Philadelphia and mid-40°s), the scale of the conference has dropped proportionally. Such is the danger of a conference whose appeal is not predicated upon the appeal of the system so much as the whim of its functional users.

After the initial learning curve, this has all been going swimmingly. I merged my first development branch into the trunk yesterday, and this branch just so happens to dovetail nicely into the whole point of this post, which is the YUI compressor, an open-source javascript and CSS minification tool developed by Yahoo’s YUI team.

The Problem

To understand quickly why one should minify production client-side code, consider only that with the upward trend of size in javascript libraries (and the necessary files for such libraries), it’s possibly to be downloading a lot of client-side code in a typical web application, especially as its scope grows.

For a long time, I was using Dean Edward’s Packer, as was everyone, because its Base62 encoding produced the very lowest file size. However, what should have been obvious to everyone is that eval(bunch_of_stuff_goes_here) is making the browser do a lot more work, and this is a problem on dinosaurs like IE6.

To make matters worse, the nature of such encoding also meant that for servers which tried to compress outgoing content like javascript (either with zlib or gzip), the compression ratio suffered. Just look at this table that Julien Lecomte posted last August.

I said to myself, “Hey, we use a lot of this stuff, and we still support a lot of users with slow computers and slow browsers.” So, I moved our project from a Packer-based compression to a YUI-based compression, and turned on server-side GZIP compression for javascript files. The only problem was that I was storing the javascript files already minified, and simply pasted them into a large a couple of large global .js files. I had to keep a separate source directory, along with any customizations.

This got to be a pain in the ass, as you might well expect, and so when it occurred to me that I might be able to use the YUI library at build-time in our Netbeans project, I immediately sprung into action.

This was around April, and one night while attending Sungard Summit in Anaheim. I did the initial work to get our Netbeans project into a state that could use the YUI compressor at build-time, creating separate source file directories and breaking our massive javascript file into modules; I did the same with our CSS, splitting it up based on what it decorated.

There are a few tutorials about using the YUI library. Some of them involve adding the YUI library to Ant’s classpath (didn’t want to go down this route); a lot of them involve invoking the library as an external executable during the build process, which is messy.

The solution I finally settled on was yui-compressor-ant-task, a small library that allows Ant to use YUI as a build task. By adding this library and the YUI compressor library to our common libraries folder, and enabling them at build only (and not for deploying in the web archive), it makes using the compressor pretty easy.

Here’s part of our build.xml:

<!--
   * minify will concatenate all of our non-TinyMCE javascripts and stylesheets
   * then use the YUI compressor library to compress them
   -->
   <target name="minify">
       <!--${libs} is path to the downloaded jars -->
       <property
           name="yui-compressor.jar"
           location="${file.reference.yuicompressor.jar}" />
       <property
           name="yui-compressor-ant-task.jar"
           location="${file.reference.yui-compressor-ant-task.jar}" />
 
       <path id="task.classpath">
           <pathelement location="${yui-compressor.jar}" />
           <pathelement location="${yui-compressor-ant-task.jar}" />
       </path>
 
       <!-- yui-compressor task definition -->
       <taskdef
           name="yui-compressor"
           classname="net.noha.tools.ant.yuicompressor.tasks.YuiCompressorTask">
 
           <classpath refid="task.classpath" />
       </taskdef>
 
       <!-- concatenation of javascript -->
       <echo message="Building global javascript" />
       <concat destfile="${build.dir}/web/common/js/global.js" force="no">
           <!-- explicitly order js concat because ordering matters here -->
           <fileset dir="${build.dir}" includes="web/common/js/jquery.js" />
           <fileset dir="${build.dir}" includes="web/common/js/jquery.bgiframe.js" />
           <fileset dir="${build.dir}" includes="web/common/js/jquery.hoverIntent.js" />
           <fileset dir="${build.dir}" includes="web/common/js/ui.core.js" />
           <fileset dir="${build.dir}" includes="web/common/js/ui.autocomplete.js" />
           <fileset dir="${build.dir}" includes="web/common/js/ui.datepicker.js" />
           <fileset dir="${build.dir}" includes="web/common/js/ui.tabs.js" />
           <fileset dir="${build.dir}" includes="web/common/js/tablesort.js" />
           <fileset dir="${build.dir}" includes="web/common/js/customsort.js" />
           <fileset dir="${build.dir}" includes="web/common/js/jquery.blockUI.js" />
           <fileset dir="${build.dir}" includes="web/common/js/jquery.form.js" />
           <fileset dir="${build.dir}" includes="web/common/js/jquery.ifixpng.js" />
           <fileset dir="${build.dir}" includes="web/common/js/jquery.superfish.js" />
           <fileset dir="${build.dir}" includes="web/common/js/jquery.cluetip.js" />
           <fileset dir="${build.dir}" includes="web/common/js/jquery.scrollTo.js" />
           <fileset dir="${build.dir}" includes="web/common/js/jquery.jqModal.js" />
           <fileset dir="${build.dir}" includes="web/common/js/validation.js" />
           <fileset dir="${build.dir}" includes="web/common/js/jquery.timeentry.js" />
       </concat>
 
       <!-- concatenation of cascading stylesheets -->
       <echo message="Building global cascading stylesheets" />
       <concat destfile="${build.dir}/web/common/css/global.css" force="no">
           <fileset dir="${build.dir}" includes="web/common/css/base.css" />
           <fileset dir="${build.dir}" includes="web/common/css/superfish.css" />
           <fileset dir="${build.dir}" includes="web/common/css/announcements.css" />
           <fileset dir="${build.dir}" includes="web/common/css/myvt.css" />
           <fileset dir="${build.dir}" includes="web/common/css/forms.css" />
           <fileset dir="${build.dir}" includes="web/common/css/cluetip.css" />   
           <fileset dir="${build.dir}" includes="web/common/css/tables.css" />
           <fileset dir="${build.dir}" includes="web/common/css/ui.tabs.css" />
           <fileset dir="${build.dir}" includes="web/common/css/ui.datepicker.css" />
           <fileset dir="${build.dir}" includes="web/common/css/ui.autocomplete.css" />
           <fileset dir="${build.dir}" includes="web/common/css/linkspan.css" />
           <fileset dir="${build.dir}" includes="web/common/css/stepMenu.css" />
           <fileset dir="${build.dir}" includes="web/common/css/print.css" />
           <fileset dir="${build.dir}" includes="web/common/css/youHaveMessages.css" />
       </concat>
 
       <!-- invoke compressor -->
       <yui-compressor warn="false" charset="UTF-8" fromdir="${build.dir}" todir="${build.dir}">
           <include name="web/common/js/global.js" />
           <include name="web/common/css/global.css" />
       </yui-compressor>
 
   </target>
 
   <!--
   * purge-src takes our compressed files, moves them to the base /common dir
   * and deletes the source js and css dirs from the build dir
   -->
   <target name="purge-src" depends="minify">
       <echo message="Purging javascript and stylesheet sources" />
 
       <move file="${build.dir}/web/common/js/global-min.js" tofile="${build.dir}/web/common/global.js"/>
       <move file="${build.dir}/web/common/css/global-min.css" tofile="${build.dir}/web/common/global.css"/>
 
       <delete dir="${build.dir}/web/common/js" />
       <delete dir="${build.dir}/web/common/css" />
 
   </target>

What you see there is essentially four steps.

1. Concatenate all the constituent source files into a global.js and a global.css
2. Compress both of these files, which creates global-min.js and global-min.css (default behavior)
3. Move these files out of the source directories and into the root of the common web directory as global.js and global.css
4. Delete the source directories in our build folder so they don’t get deployed with the web archive

Because certain browsers (IE) break without explicit ordering, we unfortunately can’t just use “*.js” and “*.css” in our concatenation step, but having to explicitly list our components in the build file certainly isn’t the end of the world. The nice thing is that the Ant task will even print out handy statistics on just how much you’ve been able to compress the files down. In our case, we have about 441.8KB of common Javascript and CSS in our source code that, by the time it gets sent to the user, has been minified and/or gzipped to about 89KB.

The Problem

Admissions needed help. They had been moved from their former product, Exeter, to Banner’s native admissions module. But Banner’s interface stinks, and there was no decent way for counselors to do, well, anything. They relied on daily reports run out of an Excel pivot table by the executive directory of admissions, and therefore they lived on paper. The counselors needed a better way to get their work done and stay on top (figuratively speaking) of their recruits.

Enter my department. It fell to us, after some discussion, to build a tool that would be initial for undergraduate counselors, to let them slice and dice their data as needed. After a pilot run, it will gradually be expanded to include graduate and transfer admissions, as well as reporting tools for directors and and other muckity-mucks.

The current iteration is 4808 lines of code, for both the views and the comment submissions servlet. Most of it was written by me, though some was reused code, and the initial servlet skeleton was written by my boss.

Setting Parameters

The first thing an admissions counselor sees is a parameter page. There are a number of options to choose from:

• Term (can be multiple)
• Population selection (e.g. active applicants, active but non-applied recruits, enrolled applicants, etc)
• Student level (can be multiple)
• Recruiter (signed-in counselors will be auto-selected (can be multiple)
• High School (can be multiple)

Selecting from term or student level repopulates the possible recruiter list with only applicable options. Selecting “Undergraduate” applicants will necessarily filter out (or should filter out) graduate admissions counselors so they’re no longer an option.

Perhaps the toughest engineering challenge here was high schools. We currently have ≈10’000 high schools in our database, and will likely have a lot more soon. Loading all those into a multiple select box would make the page huge, and likely overload some underpowered browsers. My solution? Autocomplete. Using a simple JSP fragment and the Autocomplete plugin for jQuery, I was able to make a simple autosearch/complete behavior; selecting an item drops it into a list below the input box.

The odd thing about the plugin was that it didn’t end up being very flexible about the format of returned data. I had figured it would ask you to specify a data type and do your own parsing. It seems, though, that it only wanted one format: pipe-delimited data, with newlines between records. After wrestling with it for a while, I finally got it to work, but I really would have rather just returned XML and done some simple parsing.

The Table View

Once the parameters are chosen, the user gets a very complex table (the specifications were given to us by the Admissions department).

• Name
• Term (if >1 chosen)
• High School (if >1 chosen or none specified)
• Intended major (code display; full description on hover)
• Application decision (e.g. accepted, denied, etc) (code display; full description on hover)
• Student type (e.g. new freshman, transfer, etc)
• Athlete indicator
• Registered indicator
• Application status
  • Green: complete, no pending items
  • Yellow: complete, but pending items which don’t affect admission
  • Red: incomplete: pending items affect admission
  • None (has no application; is only a recruit)
• Financial Aid
  • Green: all items complete, and aid is packaged
  • Yellow: all items complete, but aid is not yet packaged
  • Red: outstanding items; aid cannot be packaged
  • None (has no financial aid)
• Date of application
• Composite admissions score
• Date of last comment (usually a contact with applicant)
• Visited campus indicator (is not currently used)

The recruiter can export this table as an Excel document for easy printing and carrying; otherwise, clicking on a recruit/applicant’s name will bring up a detail screen, which is divided into several sections.

The Detail View

Basic

I call it basic, but this is really the most detailed tab of this entire view.

• Application-related Items
  • Entry Term
  • Source
  • Major
  • Admissions Counselor
  • Application Status
• Biographical Items
  • Banner ID
  • PIN (for helping with portal access)
  • Last Portal login
  • Student Type
  • Advisor (email link)
  • Residence (dorm icon for on-campus, car icon for commuter)
  • College (Education, Arts & Science, etc)
  • Date of Birth
  • Phone Number(s) (shows primary; expands to show others)
  • Email Address(es) (shows primary; expands to show others)
  • Address
• Holds (is only shown when there are holds on the student’s account)
  • Hold Type
  • List of items which this hold prevents
• Education
  • High School (for undergrad and transfer)
    • Name of high school
    • Graduation Date
    • GPA
    • Class rank
    • ACT composite score
  • College (for graduate and transfer)
    • Name of college
    • Dates of attendance
    • GPA transferred
• Athletics (list of sports/activities)

Checklist

The checklist is a simple table displaying pending and completed items necessary for admission. The applicant sees the exact same table when they sign into the portal, so now the counselor can see what the applicant sees.

Mailings/Contacts/Comment

This is a tripartite screen. The first and most important section is “Comments,” which is a sort of chronicle of counselors contacts with the applicant or the applicant’s parents. This screen is especially nasty using the native Banner interface, and so the object was not only to make the viewing nice, but also allow for the deletion, editing, and creation of comments.

Contacts and mailings are merely for records of correspondence the applicant or recruit has received, aggregated from several places.

Financial Aid

This screen gives detail of all awarded financial aid, as well as both completed and outstanding documents. This, too, is almost exactly what the applicant will see when signed into his or her portal.

Bill

This screen, which details charges and payments for the student, is once again a replica of screens available to the applicant when logged in. These screens are mostly to provide parity for support with applicants who have questions about financial aid, bills, or schedules.

Schedule

Once an applicant is accepted, and registers for class, this schedule tab will be filled out. It is a slight modification of the student’s schedule, which is displayed to them upon portal sign-in. Advisor see a similar view, since this is a module we reuse in several different portions of the web app.

The Big Finish

There are always bugs. I realize, just before going live, that the abbr tag that I used so heavily in the tabular view isn’t natively supported by Internet Explorer 6.

Luckily, good old Dean Edwards notes that for some reason, prefixing the namespace to the <abbr> tag makes the damn thing suddenly work, and it’s still valid XHTML! Crisis averted.

As with most of our web application, we make heavy use of jQuery. Specifically for this application, we make use of the UI Tabs plugin, the UI Autocomplete plugin, and jQuery’s native AJAX functionality. We also use the Unobtrusive Tablesort Script from Frequency Decoder, which has much better performance than jQuery equivalents.

As I said, this is only a first try at a first stage, but we’re pretty happy with the progress, and the admissions folks seem to be as well, so we’re doing something right.

Yet, I find myself at home, with a White Russian and the urge to opine.

The Background

In the summer of 2006, my workplace (The University of St. Francis, my alma mater) went live with a portal. For the previous year and half, when I was a student worker, we’d been working desperately to implement Oracle Portal. At a conference that summer, my boss, Tim, heard about uPortal, an open-source J2EE portal. On the ride back from Ohio, we more or less decided to try it on a lark. It’s basic ease of setup let us switch to uPortal and go live in 6 weeks. That’s right, a production-ready portal in 6 weeks.

Much of the work in that time was tying CAS into our LDAP implementation (Novell’s eDirectory), customizing the view (props to Virginia Tech for their excellent Tab-Column customization), and writing some basic portlets to allow quick views into student data: schedule, personal info, billing, &c. We’re a Banner school, so we could basically just reach into our Oracle database and pull the data we needed.

The Cool Bits

Since that time, we’ve poured a tremendous amount of energy into the portal, as it’s become our go-to spot for finding information and getting things done. Actually, we’ve spent very little time on uPortal at all, as it already contains much of the quick-view functionality we want. Much of what we do is a custom extension to the portal that transparently shares session data via CAS.

We have completed our portal rollout using uPortal (running on apache/tomcat), and are integrated with Sungard Banner 7.x for much of the information we pull and display, and we are using Novell E-Directory for our directory.

We used uPortal which proved to be a much more promising and easier to use platform than Oracle portal. Within 6 weeks we had our first production portal deployment. Over the last year we have built and put the following into production:

• Student Schedule and Grades Display (pulled realtime from Banner)
• WebCT Integration/SSO
• Announcements (Targeted coming by end of summer ’07)
• SSO to Novell WebMail, Netstorage, and Banner Self Serve
• Bookstore Integration with Barnes and Noble (Shopping cart of books)
• Financial Aid Portlet/Accept Loans – Display and update banner data
• Tuition Bill Portlet – Pulled in realtime from Banner AR
• Payment of Tuition Bill/Post Directly to Banner AR
• My Profile Portlet (information pulled realtime from Banner)
• GPA/Credit Hours Portlet (Pulled realtime from banner)
• Banner Security Question/Reset Password Functionality
• Expired Password Functionality
• Faculty Schedule/Class Rosters/Email Class, Export to Excel
• Banner Survey Integration
• HR Leave Balances
• Budget Reporting/Financial Activity/View Documents, checks cut, etc
• Banner Requisition Approval
• Web Based University Income/P&L Statement
• Banner Finance Journal Voucher Upload
• PIDM Usage Utility to help identify and resolve duplicate pidms
• EZProxy/Library Databases Integration
• Advancement Constituent Profiles
• Advancement Fundraising Activity Reports
• Advancement Constituent Contacts Data Entry/Reminders
• Financial Aid targeted messages
• GUAMESG
• Residence Life View your Room/Roomates
• Bulletin Boards (phpBB)
• VT Calendar
• Various Web based Reports
• E-Directory Integration/Account Creation
• Early alert and midterm warning submission, that allows the student, advisor, registrar, athletic coaches, and other support staff know when a student is having academic difficulties.
• An online advising center. Advisors can now see all of their advisees, look at who’s registered, view issues with the students account such as registration or medical holds, etc. The goal is so that advisors can also help the students get their issues resolved.
• Our initial stab at targeted announcements is done. We can now target based on the student type, level, or college as currently stored in the Banner ERP, as well as target to only employees or faculty members. The framework is in place to target off of any data element stored in Banner. Now we just need to expand our GUI allowing users to target messages.
• Accounts Receivable Reporting Suite – Our finance office now uses the portal to do various AR reporting tasks, drilling into student details, etc.
• Enrollment/Registration Status Reports – Various members of the university can now easily look at the overall student registration status through the portal.
• A faculty attendance tracking module for faculty to electronically submit the attendance of students in their classes at the beginning of term and at the mid-term point. This helps the registrar and financial aid determine who is actually attending, and replaces an old paper based process.
• On online Student Check-In procedure. Students can now confirm their class schedules, financial aid, and pay their bill through an easy to use “wizard” interface. The system will notify when they need to perform the electronic check in process before the start of the term, and then walks them through the process. This helps to collect payments sooner and determine which students are actually going to show up to class on day 1.
• Our portal now has a targeted messaging facility which looks at business rules and notifies the students of issues or action items related to their student records. For example, if a student has holds on their account the system will tell them, show them the hold, tell them what it prevents them from doing, and who to contact to resolve the hold. For students with incomplete medical records they are notified, and shown which parts of their medical records are incomplete (and for our nursing program, which shots, etc they need to have on file to be able to attend clinicals).
• A co-curricular transcript which pulls from Banner all the clubs, organizations, and sports a student has been a member of during their time at the university, and shows them in a nicely formatted page that they can print.
• A real-time registration status dashboard for administrators, deans, and faculty members. This dashboard now shows the head counts, course registration counts, credit hours, and billing hours generated for registered students, and the number of potential students who are left to register. It breaks the summary counts down in several ways: by college, major, advisor, or level (graduate, undergrad, etc). The users can drill into this report and extract lists of students who still need to get registered, whom to call to see if they need advising help or assistance registering, etc.

As the UI architect for the portal extension, I decided this past summer to standardise on jQuery, and certainly haven’t regretted it. The only bad thing about javascript is that it becomes easy to rely on it for things which should really be controlled server-side. Important validation checks, for instance. Since our ERP system has certain business logic which it enforces on the database level, we usually do two checks for important data: one (javascript) for the user’s sake, and one (servlet) for ours.

It got to the point where we were loading 10 different jQuery javascripts and 2 stylesheets in our header. Most of the javascripts were either packed or uncompressed (if packing broke them), and totaled about 200Kb. Not only was this too much, but the eval() caused a delay for each script. Recently, after one of our rollouts to production, when I got more leeway to play, I completely upgraded our script layout. I’m not going to provide an apples-to-apples comparison table here, since the prior configuration was a hodgepodge, but after minifying and turning on server-side compression for javascripts and stylesheets, I managed to reduce the load from 200Kb in 12 requests to about 50Kb in 5 requests. According to Julien Lecomte, running mod_deflate on a minified (but no obfuscated) javascript yields the lowest file size; regardless of how often that’s true, I like the idea of avoid latency from the eval(). A lot of our users are still on IE6, and they take some pretty big performance hits.

Goodness knows there’s more I could do, but given the nature of our portal (single-image CSS layouts, anyone?), it wouldn’t be a productive use of our time); I have enough crap to do with counting pixels.

jQuery rocks my socks

I might take a moment here to say just how much I love jQuery. For those of you who don’t know, jQuery is a javascript framework which abstracts a lot of functions into a much more easily-written manner. In the past, I’ve sort of been a Copy & Paste javascript programmer, since it’s been easier to use some free script than to write one’s own code. jQuery and it’s vast array (har!) of plugins makes it easy to implement or write new code. For instance, if we want to implement a support for CSS hover effects in IE, all we do is this:

$("input:text,input:password,textarea").focus(function() {
     $(this).addClass("focused");
});
 
$("input:text,input:password,textarea").blur(function() {
     $(this).removeClass("focused");
});

Easy as pie.

Granted, there are a lot of frameworks to choose from. Originally, there was only Prototype; now there’s also jQuery, Dojo, YUI, Mootools, Rico, and any one of a number of others.

The one I wanted to talk about in this post in particular is ExtJS, which was originally an extension of the YUI framework, but which eventually split off into its own project. It recently went 2.0, and boasts some rather impressive demos. I marvel at the Vista-like UI, which, admittedly, is very slick.

But the more I look at ExtJS, and half-heartedly consider its possible deployment within our portal, the less enthused I become. ExtJS’s grid, for instance, doesn’t even function on existing HTML table markup: you mass it an array of data as a javascript variable, and it creates markup on the fly… a lot of markup, in order to create it’s slick Office 2007 interface. While this is good insofar as it manages to completely abstract data from presentation, I’m not sure how much I like the idea, since it (1) relegates users to the script default without heavy customization, and (2) doesn’t allow for any kind of fallback mechanism if the javascript should fail or the user has it disabled. Our table-sorting function, in a case like that, doesn’t at all prevent the table markup and data itself from being rendered.

Work can be fun sometimes.