Recently I finished a project in which we had to add a 'hierarchical' checkbox component. The requirements were somewhat typical. Given a set of areas, for example a group of buildings under a corporate or college campus, define subareas that may themselves contain subareas. For example: PhotographyDept., 1a. Bldg1.darkroom, 1b. Bldg2.graphicsroom, ect. The hierarchical listing should emulate typical 'tree' behaviours/mouse-actions eg:
1. dynamic initialization via a server-side 'hierarchy' object
2. expand and contract.
3. check/uncheck with appropriate custom events per checkbox.
4. provide visual cues as to current state, for example indicate 'partially checked'
5. be able to reconstitute a previously saved state from persistent store
Looking around the web for example code dedicated to the general area in the requirements definition, I quickly found a number of implementations. Not suprising since the requirement definition seemed to fit a fairly common pattern. Initially I was drawn to some sizable projects that offered many configurable options and features. Giving a few of those (which I won't mention here) a test drive I found more than one worthy and ambitious implementation that appeared to fit and even exceed expectations. Attempting to put one of those solutions into place ( IE: feed the javascript library a sample hierarchy from a serverside hierarchy-generator) I was disappointed to find minutes running into several hours. Feeling like I'd been in this situation before ( a big feature-rich library becoming an implementation headache). It was becoming obvious that the widget library I was trying to implement was not going to integrate into the current project without some fairly serious javascript 'helper' code layered between the serverside object(java) and the clientside checkboxes. Furthermore it seem that the feature-rich library which looked so nifty on it's demo page was cumbersome, due to the many sub-functions and directories of helper files.
I took a step back and saw myself getting mired in a familiar squeeze, thinking there has got to be a more simple solution. Dissapointed, I fell back to considering a from-scrath solution and to googling for more example code, again paying closer attention to implementations based on well known frameworks (dojo, jQuery, yui, ect). It was then I ran across an example which seemed to do a pretty good job with the small set of checkboxes on it's demo page. I took a look at the code and was happily surprised to find a single page comprising the entire listing of variables, settings/options, and functions.
I downloaded the example ( which happened to be built on the jQuery library) and placed into my project, together with a static(hardcoded) hierarchy. The results were good, with my tree-structured checkboxes coming up with no errors. I could check/uncheck, expand/collapse, straight away. Next came the more difficult task of integrating a dynamic hierarchy. I quickly found some of the same issues as previously encountered however, with the minimal listing with which I was now working, I was able to very quickly and precisely go into the code, identify points in the code where specific actions where transpiring, and modify behavior to suit my needs. Soon I was not only able to modify the code but to add to it as necessary. This was definitely a contrast with the 'kitchen-sink' widget that initially appeared such a good fit.
At that point the solution seemed a no-brainer and I was able to code and integrate the solutions in short order. So the lesson learned here for me was less in learning yet another library extension api, but more in the area of the technology "evaluation and decision making" process.
Finally, I am in the process of obtaining permission from authors of some of the libraries upon which I based my solution. Pending that, I will post the code or a link to it here.
No comments:
Post a Comment