Tracy’s Blog

Take your work seriously…but never yourself.

‘Mo AJAX Pleeeeez?!!!

ajax.pngFew (web developers) would argue: The improved quality of user experience when navigating a JavaScript enhanced website or even a single web-page when compared with that of its non-JavaScript utilizing, post-back requiring, entire page re-rendering counterpart(s). I must confess, most of my early years in web development were spent living in paranoid fear of JavaScript. When confronted with it, I found it cryptic and foreign looking – ironic considering my extensive varietal exposure to probably a dozen or more programming languages, half a dozen technical platforms, and plethora of coding design concepts and algorithms. Still, in spite of my broad background, JavaScript freaked me out; the way it intermingled haphazardly with the HTML and executed on the client-side. Fortunately, after years of therapy and slow, gentle, indirect exposure, I’ve grown to admire and respect JavaScript’s indisputable power and user-experience improving potential. So much so, that my new web development motivational acronym is: NPB (No Post-backs); your users will thank you.

Speaking of JavaScript, I’ve continued frolicking with a plethora of the AJAX Toolkit components including the ReorderList and built-in AJAX Extension; the UpdatePanel. At the risk of sounding like a huuuuuge geek, the ReorderList control is AWESOME (once you get it working)! It’s one of the more difficult controls to get working initially, namely because the control’s sample code, at best, faintly resembles the sample displayed on the .NET AJAX website.

Here are some pointers to get you started:

  1. Copy the ReorderList and associated ObjectDataSource from the SampleToolkit Code.
  2. The associated DataSource can be any type you’d like other than an ObjectDataSource, just make sure you provide the Priority parameter for updates, insertions, and selects and a unique field identifying each of the ReorderList’s elements for updates, selects, and deletes. All remaining fields should be those relevant to the content of your ReorderList’s elements.
  3. Set the ReorderList’s DataSourceID attribute to your DataSource’s ID and the DataKeyField attribute to the unique field name.
  4. Write the corresponding queries (or stored procedures) for the select statement (be sure to order by priority here!), update statement (don’t forget to update the Priority parameter value here!), delete, and insert statements.
  5. Last, but most important, MAKE SURE you put a value into the DragHandleTemplate’s div. It doesn’t matter what; just throw something in there because without it, you won’t be able to drag your elements around and you will be baffled as to why it won’t work!!

For testing purposes, any arbitrary value(s) distinguishing each of the ReorderList elements within the ItemTemplate will do, and viola! Your control should be working; complete with database updates when you move the items around. Now for the really cool part – functionally, you can place ANYTHING within the ItemTemplate. For example, the application I’m building required users to be able to visually alter the order of blocks of reviewers for a work flow web application. In order to achieve this, I had to house 3 NESTED GRIDVIEWS within my ItemTemplate, each of which are editable/deletable, etc…and everything totally works!!

After one small change…which brings me to my next topic: UpdatePanels. Initially, these little dealios seem like a post-back avoiding savior. They’re extremely simple to implement allowing developers to essentially just execute server side, event-handler code for a control without a post-back just by including the control within an UpdatePanel. However, one soon realizes that attempting such a feat with even a slightly performance intensive control (such as a DropDownList with 1000+ elements), and the control becomes unusable; the reasons for which you will find: Here, in this person’s enlightening article.

What does this have to with a ReorderList? You’ll notice the sample ReorderList is housed within an UpdatePanel for reasons I’m not entirely certain and its presence was hosing up the performance of the controls contained within my various internal GridViews. The good news is that removing the UpdatePanel doesn’t seem to have any ill effect on the behavior of the ReorderList at all so I would suggest eliminating it altogether unless your ItemTemplate contains a level of simplicity comparable to that of the sample ReorderList’s.

That said; my mind reels (no, I don’t get out much), at the extensive use possibilities of this control. Any web application requiring users’ to declaratively order anything could potentially benefit from this control. Whether it’s a simple shopping list, or ordered favorite home prospects (complete with images and description) within a real estate website, or giant ImageMaps with routing sequences, or ANYTHING!!

At any rate, hats off to the creator of the AJAX ReorderList control for providing such a robust, adaptable, and functional tool that I can now include within my web application arsenal.

February 3, 2008 Posted by | Tech | 3 Comments

AJAX…not just for toilet cleaning anymore.

ajax.jpgOr is it?? Of course not!! Buuut, while the out-of-the-box functionality of most of the current Ajax Toolkit components do some nifty things and prove useful for fundamental, non-volume or performance intensive tasks, they also leave a lot to be desired if you’re looking for more enterprise-level applicability and functionality. As a result, I have adapted 2 of the current toolkit components for my own web application purposes when I found them lacking: the ListSearch(Extender) control and the CascadingDropDown control.

The ListSearch(Extender) is a control that incorporates a behavior already found by default in the Mozilla’s browser (but not in IE 6) whereby a user can select a DropDown (or ListBox) into focus and then type characters to auto-navigate themselves to the first corresponding record within the control. IE 6’s current behavior will only ‘remember’ a single character so when the user enters ‘TRA’ to navigate themselves to the record labeled ‘Tracy’, IE will first take them to the first record beginning with ‘T’, then the first record beginning with ‘R’, and finally the first record beginning with ‘A’; NOT the desired behavior.

Enter: The ListSearch(Extender) control which alleviates this annoying behavior within IE 6 and replaces it with the expected and desired multi-character, auto-navigate behavior. Upon discovering this splendid fact, I wasted no time in implementing the control within our company websites where corporate mandates our users browse with IE 6. Unfortunately, my excitement soon faded when I realized that a number of records within my DropDown or Listbox control exceeding ~5000, the performance of the auto-navigation became increasingly slower and was virtually un-usable when all of our required ~50,000 records were included :-(.

[Sigh]…my seemingly heroic AJAX control, it would seem, is too slow to serve its purpose; what’s a girl to do? Google it!! And discover this guy’s brilliant solution and implement it – like I did (or better yet…just download the 10920 version of the Toolkit where the Mr.Brilliant has now pre-included his fix ^_^). Oh, hhhappy days are heeere agaaaaain…

Now then AJAX control #2, the handy-dandy CascadingDropDown. This control’s preliminary description lent itself to be highly useful for our gee-gan-tay search pages where our users select a bunch of different filter criteria from a bunch of different Dropdown/Listbox controls, then ‘Submit’ to obtain their associated results, only to learn that they’ve selected a combination of criteria that doesn’t exist and they’ll now have to ‘guess’ which selection item(s) need to be altered.

Anyone who’s tried to alleviate this problem by dynamically auto-populating the controls with a number of records based upon the user’s selections server-side has quickly figured out the ree-dic-u-luss postback times associated with the necessary page re-rendering.

Enter: The CascadingDropDown control which dynamically populates the Dropdown contents via JavaScript and Web Method (yippee, no more postback delay!!). But, before one begins a premature celebration, the controls’ associated DropDown can only have a single other DropDown control’s contents influencing its own contents (read: One parent). OH…the humanity of it all!! And what do we do when the standard AJAX control fails us? Google it!!

This time, however, Google did not reveal any Mr. (or Ms.) Brilliant’s to me which left me no alternative but to modify the control code myself to accommodate multiple influential parent controls.  Here is the JavaScript source file which should be the only file you need to change within the control and some examples of the new control’s use.

In a nutshell, the control behaves the same as its predecessor (so I recommend successfully implementing it before attempting this one since that will throw enough of a learning curve at you initially), with the exception of the ability to enter a comma delimited (space free!!) list of parent ID’s within the CascadingDropDown’s ParentControlID attribute rather than just a single ID value. With that, the indicated control’s associated web method will be called every-time any of those parent controls’ selected-values is changed by the user.

Due to the fact that the order in which the web methods are called must remain arbitrary, there are a few caveats to remember:

  • You must always have a non-filtering, generic option appearing as the FIRST value in the dropdown that represents a ‘return all selections’ selection (All).
  • In addition, this item’s Value Field must not match any of the other item’s values and it must not equal -1 (you’ll notice I used -5 in my webservice example)
  • You must indicate this item as all related CascadingDropDown’s SelectedValue attribute. (see example .aspx).
  • NO SPACES between the parent id’s:
    • Good: ParentControlID=”ddlModel,ddlColor”
    • Bad: ParentControlID=”ddlModel, ddlColor”

Otherwise, everything else works pretty much the same; you’ll still receive a semi-colon delimited list of all parent Categories and their current selected values in the knownCategoryValues parameter of the web method with which you can dynamically determine the DropDown’s contents.

As a note, testing has indicated that the Dropdown’s each seem to be good for a maximum of ~800 records before they die.  I’m not sure why, but that certainly limits the usefulness of this tool.

I personally could really use an AJAX tool similar to this one without the ‘cascading’ quality.  I’d like it to simply populate a single DropDownList via a Web Method (alleviating the postback), but able to handle upwards of 50,000 records without a problem.   Any takers?? ^_^

Feel free to report suggestions, criticisms, observations, or questions and…happy cleaning!!


Just a little hint if this is the first time you’ve modified an ajax control: if you just open the entire AjaxControlToolkit solution file when you edit a control, re-building the solution will take a little while (about 15-30 seconds) regardless of the fact that Visual Studio displays ‘Ready’ in the lower-left corner. Wait until it says ‘Build Succeeded’ in the lower-left corner and the little bucket icon with the 2 moving green arrows in the bottom-middle of the screen has disappeared.

January 22, 2008 Posted by | Tech | 1 Comment


DeclareFirst, I must apologize to my frequent blog-reader [singular] for the recent lack of new postings. Unfortunately, my current employer has become rather Nazi-like with their website restrictions which I find particularly hindering considering much of my work involves problem-solving via research using web search engines. Sad is the day a company feels it can no longer trust its own employees. Nonetheless…I will not be silenced! “The Man’s” futile attempts to squelch my free-speech frenzy shall not succeed; my voice will continue to echo across the mountaintops of Blog-land!

Anyhoot…onto the bloggin’ topic: The savage .NET 2.0 battle rages between declarative server control initiation versus programmatic server control initiation and maintenance. Here is one such fellow blogger touting his preference for the pragmatic, programmatic methodology.

And here’s my 2 cents: When first introduced to asp.NET 2.0, I, too, found the declarative server tags and DataSourceControl-populating wizards somewhat disconcerting, creepy, and a little too Dreamweaver for my taste. “I’m a real programmer”, I kept thinking, “I’ve dredged my way through the ugliest, most-cryptic of programming coding (that’s right, I’ve had to work with Prolog) and I certainly DON’T need any wizard to do my programming for me.” I was suffering from what the professionals like to call ‘Old-Skool-izm’.

Relatively soon, it became quite clear which side of the coin Microsoft’s developers had contributed vastly superior resources towards planning, implementation and even documentation efforts; the declarative side. After MANY frustrating scenarios (and multiple blog postings) working with a variety of server controls in a stubborn, strictly programmatic manner, I found myself fixing many of the inexplicable, unintuitive server control symptoms and behaviors by simply switching to declarative mechanisms.

As time rolled on, and continued to plunge headfirst into the code-reducing, time-saving declarative devices, I found myself wondering why I had so fervently resisted them for so long. Certainly there are times when a programmatic method is necessary for a certain echelon of dynamic server control behavior, but when it’s not; why write more code than I have to? And furthermore, why not allow Microsoft’s framework to invisibly do the heavy lifting for me in terms of maintaining a control’s state?

On that note, I recently discovered what I considered to be a somewhat obscure ViewState symptom of populating a server control programmatically rather than declaratively. If you rely on a server control’s view state to retain its data across postbacks, so that you’re not required to continuously re-load the control every time the page refreshes, asp will store your entire data set for that control in view state (that’s about 136 lines x 1024 characters worth of view state for a single DropDownList control populated with approximately 5000 records). This is because all changes made to server controls via the code-behind file are lumped in with asp’s interpreted “user-initiated control changes” and so are preserved within view state rather than stored server-side.

Alternatively, declaratively binding a server control to a DataSource object, such as a SQLDataSource or an ObjectDataSource, will store the control’s associated dataset server-side eliminating the size-able view state that will travel to/from server and users’ browsers for each page request.

Similarly, any property setting changes made to controls in a programmatic manner, such as the control’s styles, maxLength, databindings, etc will ALSO be recorded and maintained within the page’s view state. Is one’s view state really a consideration when we’re talking about view state hogging rich server controls such as the GridView? Probably not, but it’s food for thought.

December 12, 2007 Posted by | Tech | Leave a comment

More Fun with XML (and SQL Server 2005)

Standing on SHoulder There is simply nothing more fulfilling and gratifying in the world of software development than solving a tough problem with an elegant, robust and scaleable solution.

Welllll…exxxxcept for googling your problem, standing on the shoulders of other programming geniuses, and using their elegant, robust, and scaleable solutions to solve your own tough problem. Programmers are inherently lazy and I’m no exception. So when I stumbled onto this little URL gem describing an elegant, scaleable, robust and plug-n-play-like method to providing a dynamic and variable number of parameters to a SQL stored procedure; I thought I’d share it with my fellow engineers.

Passing Lists to SQL Server 2005 with XML parameters.

[FYI; you must have Sql Server 2005 or greater].

December 12, 2007 Posted by | Tech | Leave a comment

The GridView’s GREAT From Up Here!!

ViewI recently found myself frolicking in the land of .NET 2.0 SqlDataSources and editable GridViews. After reading numerous excerpts touting the flexibility and ease with which web developers can now achieve virtually Excel-like interfaces between users and their data, I was stoked to try it all out.

In retrospect, I will certainly award snaps to those MS peepz for their notable effort towards predicting and facilitating the common-place task of giving web application users discriminating access to database stored information. I can only imagine the daunting task of attempting to allow for all derivations of developers’ preferences (Lord knows we’re opinionated if nothing else) while at the same time maintaining a minimal level of Integrated Development Environment complexity in order to achieve some element of intuition.

That said, I had a bit of trouble getting my (basic) editable GridView to work utilizing VS’s all-encompassing, plug ‘n play, SqlDataSource functionality. The predominant factor in my troubles were the subtle differences with which VS handles defining one’s SqlDataSource select/update functions via referencing stored procedures versus defining them with embedding SQL statements directly within Visual Studio’s SqlDataSource configuration wizard.

I’m happy to report that after a good night’s sleep and some professional help, however, I worked my way through the cryptic behavior and resolved all the issues. Here are the ‘GOTCHAS’ I encountered, in the hopes of alleviating [some of] a fellow developer’s trauma while exploring the wide world of editable GridView’s.

Behavior #1: No errors being generated and no exceptions being thrown, but the GridView’s update function just doesn’t do anything. I encountered this problem when the condition within my Update stored procedure was not being met [WHERE MAIN_ID = @MAIN_ID]. Unfortunately the reason(s) the condition was failing weren’t obvious.

  • Reason #1: As stupid as I feel admitting this, I’m going to do it for the sake of others who could be making a similar error. I wasn’t including the MAIN_ID field within my GridView’s select query. VS did not generate any type of error in spite of the fact that I was declaring a parameter named @MAIN_ID within my Update function that was not included as part of my GridView’s select query, but maybe that’s so they can allow for extraneous GridView column additions. At any rate, my ‘where’ condition failed in this case (obviously!) since it likely had a value of ‘NULL’ for the @MAIN_ID input parameter value.
  • Reason #2: If you’re referencing a stored procedure for your GridView’s select query, you’re likely missing the necessary DataKeyNames attribute value within your GridView element. At a minimum, this attribute needs to hold the name of the field(s) you’re using within the where clause of your update statement (in my case, I need DataKeyNames=”MAIN_ID”). From what I can tell, VS will auto-populate this attribute if you’re embedding the SQL directly within its SqlDataSource wizard with the names of any primary key columns it encounters, but no such auto-population will occur, nor will any errors/exceptions be generated when you’re referencing your own stored procedure.

Behavior #2: A ‘Procedure or function [your procedure’s name here] has too many arguments specified.’ exception gets thrown when you attempt to update a record within the Gridview.

  • Another dissimilar behavior characteristic between using embedding SQL versus a referenced stored procedure is VS’s ability to automatically determine the fields that should be included as parameters within the GridView’s update statement. When using embedded SQL, the update parameters will be automatically limited to those elements included within your SqlDataSource’s element regardless of the number of BoundFields you have listed within your GridView. However, when referencing a stored procedure every BoundField that does not contain a ReadOnly attribute value of ‘True’ (and BTW it’s default value is ‘False’) will be included as a parameter and sent to your stored procedure REGARDLESS of what you have listed as . This seems highly un-intuitive to me, too, but it’s an easy fix once you know that’s what’s going on. You can either change each of the BoundFields that you don’t want included as update parameters to have a ReadOnly attribute value of ‘true’ or you can go ahead an include their column names as input parameters within your stored procedure (@CURRENT_STATUS_DESCRIPTION) and just do nothing with them.

As a sidenote, here are a couple of incorrect/outdated solutions I encountered on other forums and wasted time pursuing:

  • Solution #1: The = comparison issue. One forum claimed that if you were including nullable columns within your GridView and attempted to update a column with a current value of NULL, the GridView’s update procedure would attempt a = comparison, which would return false and halt the execution. I found no such behavior in my .NET 2.0 Framework and SQL Server 2000 configuration.
  • Solution #2: Anything to do with the value contained within SqlDataSource’s ConflictDetection attribute. After wasting time on this one, I wound up using the default value (easily achievable by just omitting the attribute altogether) and everything’s working just fine.
  • Solution #3: Anything to do with the value contained within SqlDataSource’s OldValuesParameterFormatString attribute. [See solution #2].

Other than that, Mrs. Lincoln…how was the play?

December 12, 2007 Posted by | Tech | 1 Comment

Cooking With XSLT

cooking1.gif At the risk of sounding like the biggest geek in the world (waaaaay to late in the game to be worried about that anyway) – XSLT is starting to reveal itself as a remarkably flexible language with a high coolness factor. Short for eXtensible Stylesheet Language Transformation. XSLT is a functional language designed to transform XML into HTML, XHTML, PDF, other XML formats, or basically anything else you want to output from it. XML is basically just style-stripped text organized into a meaningful hierarchical format. If you’ve every worked with SGML, XML is basically just the well-formed version of SGML (think Twins, the movie, with Schwartzneggar and DeVito – XML is the kid every parent wishes for and SGML is its job-hopping, looser, screw-up brother).

Anyhoo, back to the coolness factor surrounding this language. I first had the pleasure of working with XSLT when a former employer dubbed me the team “Stylesheet Expert” and tasked me with converting numerous XML military technical manual documents into HTML and PDF format. I refer to it as a pleasurable experience now, but the language of XSLT is very far removed from the functionality of most other mainstream languages out there (C, C++, C#, Java, etc.) and it was a serious pain in the brain trying to understand how it does what it does. For instance, XSLT does not have true variables in the way most other languages do, rather its variables are more like constants and the language itself is purely recursive, not iterative; another far cry from most other languages I’d worked with.

In spite of our initial quarrels, eventually XSLT and I learned to get along quite well and my most recent employer stumbled onto my hidden talent and tasked me with developing stylesheets for their military technical manual XML documents. This time, though, I had some slightly more severe requirements from the client and I’ve gotten a real taste of just how powerful XSLT can really be.

The website itself was quite straight-forward; some simple Javascript for dynamic table of contents behavior, a slew of internal/external cross-document links, but otherwise quite static and mellow. There was, however, an enthusiastic request for some search box functionality. Not a big deal until I learned the clients (military peepz) were not real excited about any third party packages or extensions being included on the distribution CD and the red tape required to get approval for such an inclusion was soooooo not worth the time or effort.

After some google searching I found a couple of simple scripts that would strategically escape a search phrase typed into a text-box and then hunt through delimited strings of text within an array for a match. Would this be a truly useful methodology for a traditional website; probably not if it were a sizable site with plentiful content, but for my situation, it was absolutely perfect. I could dynamically construct, not only the Javascript itself, but the javascript array of content; dividing the text into chunks according to the pages and URLS I was creating on the fly. It worked like a charm and took me maybe a couple of hours to write code that filled a couple thousand element sized array with every bit of content of the entire website. And best of all, I would never have to worry about updating the array when changes/additions were made to the site content; just a simple command line utility to reprocess the updated XML and viola – any new content is automatically integrated into the site.

Composing a website using XSLT is alot like writing a recipe that matches all the ingredients you already happen to have lying around your kitchen, to prepare exactly the meal you’re craving. XSLT is not necessarily ideal for all situations, but if you’re responsible for maintaining/developing multiple sites with virtually identical templates, or the content of your site changes heavily and frequently, but the template in which you display it does not, ooooor you’re just a big geek like me and feel like tinkering around with some “cool” [in every un-cool sense of the word] technology – then take it for a test drive.

Some useful links:

There is no ‘I’ in style-sheet so feel free to drop me a line if you need any assistance my fellow XSLT-ers.
Good luck and happy transforming!!

December 12, 2007 Posted by | Tech | Leave a comment

Coding Kharma

budda1.jpgFor the love of all that is holy in this godforsaken world…pleeeez, pleeeeez, pleeeeez, when you’re writing your code, consider the people who are going to have to modify and debug it down the road. I am fully prepared to launch myself off the 2nd story of this building right now because I’m trying to fix yet another program written by my coding nemesis: let’s just call him T.C., short for Terrible Coder (oh, yea, I went there). T.C. is the programmer whose place I took in my current position whom I’ve never actually met, but from all accounts by my co-workers was a squirrely, unhygienic fellow with a preference for hippo-like women and who, hands down, has written the most unmaintainable, nightmarish code I’ve ever seen in my limited life.

Here are a few token characteristics of TC’s code:

  1. Never a single comment of any kind.
  2. Never any modularity of any kind; if TC does write functions, there’s no logical separation and they’re typically anywhere from 100-600 lines of code per function.
  3. No logical organization of any kind within the code itself; the order of the programs seem to simply mimic TC’s haphazard thought patterns.
  4. Extraneous code (this is the worst part). TC will often leave code in his programs that does absolutely nothing; like requesting session variables that don’t actually exist at the beginning of the file and then never actually using them.

Fellow programmers, we’re all in this together, writing code, modifying other’s code; it’s like one big programming circle of life. We’re all ultimately serving the same purpose and none of us wants to be considering ending our own life because of a lazy, incompetent fellow developer’s work. Furthermore, it is a well known fact that all of the coding horror you create for fellow programmers due to your malicious and incompetent coding practices will be visited upon you 10 fold. So do yourself a favor and practice friendly coding techniques for good coding kharma.

December 12, 2007 Posted by | Tech | Leave a comment

Re: The Top 10 Dead (or Dying) Computer Skills

The Top 10 Dead (or Dying) Computer Skills; what this article should really be called is: “If You Don’t Already Know This Stuff, Don’t Bother Learning It”

I don’t believe one’s livelihood is in jeopardy who possesses [most of] these skills, quite the contrary. Due to the once severe popularity of some of the listed technologies and the potential decline of compatible software/hardware, there will be a multitude of clients requiring the conversion of legacy code.

There is a significant delay between the time a technology is deemed ‘on the way out’ and the time it actually exits the industry. I myself spent 3 days of last week enhancing and debugging a web page written in Perl with a Microsoft Access back-end database; it sucked.

The volatile nature of this industry simply requires that those who wish to remain necessary within it, never stop learning. My limited experience within this industry so far has led me to believe there’s no sure-fire recipe for learning the most coveted technologies so that you can excel the fastest and earn the most. The key is learning as much as you can as often as you can; whether it’s proprietary Microsoft technology, open-source free ware, architecture concepts, or best database practices, etc. You can never have too much knowledge. The more knowledge you have to draw on, the more tasks you’ll be able to tackle and the more employers you’ll be appealing to. And the odds are, you will draw upon all of it at some point.

December 12, 2007 Posted by | Tech | Leave a comment