Sponsored By Aspose - File Format APIs for .NET

Aspose are the market leader of .NET APIs for file business formats – natively work with DOCX, XLSX, PPT, PDF, MSG, MPP, images formats and many more!

Client-side scripting, eight years on

There’s a point to this and a request for suggestions at the end so don’t be alarmed by the meandering I’m doing at the beginning.

The Hillbilly is a bit of a black sheep in his family. I have three brothers, all of whom are land surveyors working in the family business in western Manitoba. My mother, a retired nurse, is also on the payroll as the Office Dictator (according to her business card anyway). It’s an odd kind of environment out in their world, what I’ve often called "Deliverance Country". They have theme days like many other companies but you’re more apt to hear them celebrate "Potty Mouth Friday", where they swear like sailors all day, rather than "Casual Friday". (We won’t go into the details of Racial Slur Wednesday followed by Repentance Thursday.) And their day-to-day activity is that kind of controlled chaos inherent to small businesses that do actual work while the rest of us blither on about whether our corporate portal is using a colour scheme that won’t offend the accounting department’s hatred of pastel.

They use an application I wrote nigh on eight years ago in classic ASP that makes heavy use of XMLHTTP and DHTML before it had a name that sounded less Klingon when pronounced phonetically. In it, there is a screen that creates a Job object (ok, it doesn’t actually use objects because I was young and it was ASP but let’s make an ass out of u and me for a minute).

On that same screen, they can attach one or more locations to the Job as well as remove any existing ones. This is done using DHTML to add and remove table rows dynamically to a running list. Behind the scenes, it maintains an XML document containing all the job information, including the list of locations. On form submission, all the form elements are ignored and the XML document is the piece that gets processed.

As I said, this was eight years ago. I’m in the process of updating this same application and my first order of business is to duplicate the functionality of the existing app (which is much more than what I’ve already described, except for a search feature). And I’m implementing the Edit Job screen and discovering that after eight years, there doesn’t seem to be a better way of building this screen.

Yes, there have been advances in scripting languages and techniques. I’m starting to use jQuery which is kilometers/miles faster than using the DOM natively but is not going to win over the hearts of any web developers looking into Javascript for the first time. It’s a great framework for those of us familiar with how hard it is to do this stuff without it though.

But I’m talking about the underlying method in which I would build this screen. However cleaned up it may be, there is still direct manipulation of HTML elements. There is still the storage and manipulation of data in the browser. And XML is still a very viable alternative for that storage. I have a feeling JSON might be more suitable but neither option is very palatable.

For example, in C# 1.0, how would you find a particular element in a collection? Loop through the list until you find it. In C# 2.0: probably use the Find method on the list with a delegate. In C# 3.0: lambda expressions maybe.

In Javascript today, as you did eight years ago, you loop through the list. Or you use selectSingleNode on an XML document, just as you did eight years ago.

Now, jQuery does alleviate this quite a bit with some pretty advanced use of selectors. But in the end, you’re still searching through an XML document. Or a JSON object which, despite the simpler syntax, still is kind of funky to traverse and add/remove items from.

I’m not sure how my ideal way to build this screen would be exactly. I just have this feeling that, after eight years, it should be easier than it is.

And maybe it is. Which brings me to the real reason for this post. How would *you* build such a screen? Remember, you’re adding/removing items to a collection on the page client-side and submitting the data all at once. The items are not selected from a list, they are entered mostly free-form by the user (I’m paraphrasing seriously but don’t want to go into the details of the section/township/range syntax). Think of it as creating a shopping list with some extra metadata at the top (e.g. name of the shopper, date the list was made, etc).

Would you do DOM manipulation with jQuery or prototype or whatever? If so, how would you maintain the state of the object in the browser? Or would you have a postback everytime an item was added to the list and maintain it in a state on the server? Or is this something that Script# or something akin was born to deal with? Or…?

I welcome any and all suggestions and would love to post a follow up to summarize them at a later date.

Kyle the Client-Side

This entry was posted in Javascript. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Kyle Baley

    It’s not hard to create an AJAX controller to render a partial view. Nikhil Kotari’s already done it in a more generic way than I would for a specific project (http://www.nikhilk.net/Ajax-MVC.aspx). In my case, I don’t know if I’d want to go to the server to perform what is essentially a client-side action. I’m not doing any database manipulation nor am I working with any server resources. On the other hand, it would be a lot easier to do this in C# than in JavaScript. But if I were going to do that, I’d probably take a long hard look at Silverlight.

  • http://www.tobinharris.com/blog Tobin Harris

    Ahh, didn’t realise you were in MVC.

    Well, I’m a Ruby on Rails developer too, and the same approach would work in Rails. Except I’d use Ajax to re-render a partial view rather than an update panel.

    So, I’d have a controller method called update_locations, which would be called by an XMLHttp Ajax request, and in turn update the model (a temporary XML file for example), and then end by re-rendering the partial via Ajax to reflect the latest data.

    From what I’ve seen of ASP.NET MVC (just watched the MIX08 video), it should be doable in ASP.NET also, although I’m not sure how far they’ve got with their Ajax helpers.

  • Kyle Baley

    Actually, I hadn’t thought about it really. But I don’t think the UpdatePanel is something I want to deal with in MVC. It’s whole purpose is to AJAX-ize the ViewState of a control. And MVC is all about getting rid of the viewstate idea altogether.

  • http://www.tobinharris.com/blog Tobin Harris

    Rather than doing DOM manipulation, what about this….

    Have a GridView sat in an UpdatePanel or equivilent.

    After user updates the view, do CallBack to update the model accordingley on the server. Then re-bind the model to the GridView and Ajax refresh the panel.

    I guess you must have thought of this!!!?

  • http://weblogs.asp.net/dotjosh Josh Schwartzberg

    It’s funny you pose this question, because I have a similar situation at work. We have some heavy javascript code using xml as a temporary storage that we ship to and from the clients browser and the web server for processing. The amount of javascript has gotten out of hand and so we’ve considered other solutions.
    We’d like to especially gain testability without having our page be too chatty and hinder performance on slower connections, so we’ve kept our eye on silverlight closely (specifically 2.0 so we can use the CLR). We don’t want to replace our entire site with silverlight just yet, just this particular section of the screen that contains the abundant amounts of complexity and special ui elements. Maybe that’s an option for you to look at.

  • Kyle Baley

    @Ayende: Not sure if that’s meant as a rhetorical question. Hard to tell in text form. If you mean that we’re still using the same HTML and ECMA specs, then yes, that would explain why there hasn’t been much advancement. And I understand why that’s stayed the same compared with a proprietary language like C#. Doesn’t mean I have to like it though.

    @Mark: That’s pretty cool, even if you still need to loop through the list. That and the script libraries like jQuery, prototype, et al are, in my opinion, the big advances. Not in the language itself, just in the way we use them.

    Back to the question at hand, though. Is storing a representation of an object on the client in XML or JSON format a viable approach? ‘Cause neither format is that natural to work with.

  • http://www.markagrant.com Mark Grant

    “In Javascript today, as you did eight years ago, you loop through the list.”

    Actually, its fairly straightforward to create a List.Find function using anonymous delegates in Javascript. Looks a bit like:

    list.find = function(collection, predicate)
    {
    for (var i = 0, length = collection.length; i < length; i++)
    {
    if(predicate(collection[i]))
    {
    return collection[i];
    }
    }
    }

    So its pretty easy to upgrade your javascript to c# 2.0 style. On the other hand the lambda expressions are a bit of a problem as they are a domain specific language (within c#).

  • http://www.ayende.com/Blog/ Ayende Rahien

    Let me reverse this question.
    What significant change has happened in the web world in the last 8 years?