Doron's .NET Space

ArcGIS Web ADF 9.3 – Is it Any Better?

dorony — Sat, 13 Jun 2009 20:53:36 GMT

A while back I’ve posted my opinion about the ArcGIS Web ADF 9.2. It wasn’t a positive one. Since then, I’ve had a chance to work a little with the new version – the ADF 9.3, and even attended a seminar held by Rex Hansen, which – as I understood - is one of the main contributors to the design of the Web ADF.

On the surface it seems that the Web ADF took a leap forward at 9.3. It is now built upon the Microsoft Ajax library, instead of ESRI’s own callback-based solution (you know, the whole ICallbackEventHandler headache). Performance should be better, as the map now uses a custom .ashx handler to serve the images, instead of doing a bunch of full postbacks. But the question that remains is – Is the API any better? Are simple stuff simple? Is customization any easier?

Sadly, the answer to that seems to be a big NO. Almost none of the issues I addressed in my original post were fixed. The API is still overly complex. Resources, functionalities and all these so-called abstractions remain in place, emphasizing the strength of the JavaScript API’s simplicity. And yes, there are still about a billion classes that are named “Converter” in the API. It seems like ESRI insists that you write the entire namespace before every class you use.

Ajax is a bit easier this time around, since we can use ScriptManager to register client scripts, but it still took us a while to figure out how to make it all play nicely together (this article provides some solutions, by the way). I hate having to read mountains of documentation before I can get anything done (on the bright side – at least there is documentation), and trying to explain a newbie programmer about the difference between a “partial postback” and a callback is hard.

There are some more unpleasant surprises for you here. Noam Sheffer (hebrew link) mailed me about a problem he had. It seems that the map control still initiates a full postback to the page with every zoom operation. This is of course bad for performance, and also caused him issues with maintaining the state of some of his controls. Checking out an example site with Fiddler or Firebug, can show you that this is indeed the case.

And a word about the seminar by Rex Hansen. He showed some of the product’s new features, performance tips, and solutions to common problems. Thing is, I don’t care about being able to customize the MapTips template. It shows that ESRI focus is on the wrong thing – instead of simplifying the API, they’re adding more features so that it is even more complex.

Therefore, I still recommend anyone with a choice to go for one of the REST APIs. I’ve only worked with the JavaScript APIs, but I hear that Silverlight and Flex are similar and are equally simple. For now, I’m keeping my strong belief that doing anything complex with the Web ADF is putting yourself in a world of hurt.

ArcGIS JavaScript API: IE Memory Leak Fix

dorony — Sat, 09 May 2009 09:30:53 GMT

Since version 1.2 of the ArcGIS Javascript API, we've noticed a strange issue in both IE6 and IE7. When zooming in, memory consumption of the iexplore.exe process takes a huge jump and reaches up to 800-900 megabytes. When the operation ends, it goes back down to 50-60 megabytes. This has caused us a great deal of sorrow, as it sometimes caused our users' systems to hang.

This post in the ESRI forums explains, and also provides a fix. Apparently, the upgrade to dojo 1.2 has caused this zoom-animation related issue. To fix it, you should create a javascript file with this text:

/*
 * override the dojo 1.2, 1.3 version of dojo._setOpacity to revert back to the dojo 1.1 implementation
 * this version doesnt allow multiple filters on an element, but it is free from the memory spike issue */
(function() {
  var d = dojo;
  if(dojo.isIE) {
    dojo._setOpacity = function(/*DomNode*/node, /*Number*/opacity){
      if(opacity == 1){
        var filterRE = /FILTER:[^;]*;?/i;
        node.style.cssText = node.style.cssText.replace(filterRE, "");
        if(node.nodeName.toLowerCase() == "tr"){
          d.query("> td", node).forEach(function(i){
            i.style.cssText = i.style.cssText.replace(filterRE, "");
          });
        }
      }else{
        var o = "Alpha(Opacity="+ opacity * 100 +")";
        node.style.filter = o;
      }
      if(node.nodeName.toLowerCase() == "tr"){
        d.query("> td", node).forEach(function(i){
          i.style.filter = o;
        });
      }
      return opacity;
    };
  }
})();

Reference this javascript file from every page that has a reference to the Javascript API, and you're good to go.

Still, one can't help but wonder how the ESRI QA guys didn't notice this obvious shortcoming (which will be fixed at 1.4, they claim). Maybe they only used machines with lots of RAM. That's how we missed this at first... :)

Writing Maintainable Javascript Guidelines

dorony — Fri, 03 Apr 2009 18:08:49 GMT

We've been doing a lot of Javascript development lately, while writing an Ajax-based web application. Up until recently, my team's Javascript experience consisted mainly of the occasional disable-that-checkbox function inside an .aspx web-form. Nothing wrong with that, I guess, but it doesn't really count. If you're going to write a lot of Javascript, you have to do so in an organized and clean way, or you'll have a maintenance nightmare on your hands.

This is not because Javascript is a bad language. It can be quite beautiful actually. But it does allow to work in ways that are not elegant, so I would like to show you some tips on what you should do, and what you should avoid - Framework Design Guidelines style.

DO use separate .js files to store your Javascript code.

AVOID writing a lot of Javascript inside an .aspx form.

When you do the shift to a heavily scripted client, and you begin writing loads of Javascript, this approach fails miserably, for several reasons:

Performance - .js files are usually cached on the client side, and .aspx are not, as they usually contain dynamic data. Also, .js files can usually be compressed, so they get even lighter to download.
Maintenance - It is just easier to maintain the script code when it is in a separate file.

DO use different .js files for different modules.

It might seem obvious, but I've seen .js files that contain thousands of lines of un-related code. Again, this is hard to maintain. In C# we like having a separate file for each class, don't we? Well, Javascript shouldn't be a lot different. If you're worried about the performance penalty of having many files, there are tools you can use to combine your scripts to a single file on deployment.

DO use a Javascript library instead of rolling your own infrastructure.

Really, these days it is just silly to write your own Ajax implementation, or your own collection types. Libraries like jQuery, ASP.NET Ajax and Dojo, already do so much for you. This will save you a lot of time and effort, and will also allow you to create cross-browser Javascript that works even on crappy-old browsers such as IE6.

CONSIDER writing only object-oriented Javascript.

Most Javascript libraries will allow you to write your code in an object-oriented manner, based on the prototype model available in the language. Object oriented code is easier to follow and understand. And yes, you even get the benefits of inheritance, design-patterns and all that good OO stuff you know from C#. Here's how a class in the Dojo library is declared:

dojo.declare("Person", null, {         
   constructor: function(name, age, currentResidence){
        this.name=name;
        this.age=age;
        this.currentResidence=currentResidence;
    },
    moveToNewCity: function(newState) 
    {
        this.currentResidence=newState;
    } 

});

As you can see, we have a constructor, fields, methods and all.

AVOID using a lot of global variables and functions.

This is really just good programming behavior. Globals are bad! That's what they always used to tell you, and this is still correct. Unlike C# or Java, Javascript allows you to define global variables and global functions. In fact, for many this is the standard way of scripting. I know it was for me. But when you start having hundreds and thousands lines of code, which access some variable that was defined in god-only-knows-where, you'll see that it's a bad idea. When you have 5, 10 or 20 .js files, you just don't want to take the chance that two of them define the same function or variable, do you?

Granted, you can't avoid using some globals, but you should keep this to a bare minimum. Our pattern for global functions is to use them as gateway-only to some class. Usually they will be event-handlers which just create a class and call one of its methods. We pass data around from constructor to constructor instead of defining it globally.

AVOID specifing an Html element ID in a class declaration.

This is bad:

dojo.declare("ButtonHider", null, {         
   hide: function() 
    {
         $get('MyButton').style.display = 'none';
    }

This is good:

dojo.declare("ButtonHider", null, {         
   hide: function(buttonId) 
    {
         $get(buttonId).style.display = 'none';
    }

Also good:

dojo.declare("ButtonHider", null, {         
    constructor: function(buttonId) {    
        this.buttonId = buttonId;
    }
       hide: function() {
         $get(this.buttonId).style.display = 'none';
    }

Not only this makes your code more generic, but in ASP.NET is essential. ID's for server controls can easily be changed if they're dropped inside some container. You'll want to pass the ClientID property of the button you want to hide to the class above, and not the actual ID.

DO remember that Javascript is a functional and dynamic language, and use that to make your code more readable.

Functions can be passed around as data in Javascript. Properties and methods can be added to any object. You can misuse these features, of course, but when used correctly they make Javascript a very powerful language. Having classes doesn't make it C# code! Here's a StackOverflow thread to get you started on some of Javascript's less known features.

DO maintain coding standards to your Javascript.

If you want your code to be readable, you need to have standards. Among other things, we use camelCase naming for functions, use underscore prefix to signal "private" members (even if the language does allow them to be accessed outside, the underscore suggest the user of your code to not do so), and use the syntax 'var arr = [];' to define an Array (and never 'new Array()'). What are your standards? Define them, and have everyone follow them.

CONSIDER writing unit-tests for your Javascript.

I admit we're still taking baby-steps in that direction, but as our code-base gets more and more complex, we'll have to cover it with unit-tests for it not to break on us. Here are some frameworks recommendations we're considering to aid us in that.

To conclude, I would like to say that crappy code can be written in any language. If your application is Javascript oriented, it is no excuse to write bad code. The guidelines I have put are nothing new. Mainly, they only remind you to also use them when writing Javascript, and not only in your favorite compiled language.

ESRI JavaScript API: Now with Error Handling

dorony — Tue, 03 Mar 2009 17:58:18 GMT

The JavaScript API v1.3 has been released, and it now supports error and timeout handling. Finally! We actually had gone and implemented this feature ourselves by overriding the esri.request function, but it was a hack that we'll be glad to be rid off. I can't really understand why this wasn't there to begin with, but still - happyness.

Pretty Quick Sort With C# 3.0

dorony — Thu, 29 Jan 2009 19:28:41 GMT

Jafar Husain writes about the prettiness of F#'s type inference, but what I really liked in his post was his C# 3.0 implementation for Quick Sort:

 1 public static IEnumerable<T> QuickSort<T>(this IEnumerable<T> list)
 2 where T : IComparable
 3 {
 4     if (!list.Any())
 5     {
 6         return Enumerable.Empty<T>();
 7     }
 8     var pivot = list.First();
 9     var smaller = list.Where(item => item.CompareTo(pivot) <= 0).QuickSort();
10     var larger = list.Where(item => item.CompareTo(pivot) > 0).QuickSort();
11 
12     return smaller.Concat(new[]{pivot}).Concat(larger);
13 }

Yes, the F# implementation is more concise, but Jafar really reminded how concise can C# be as well. When I first heard about C# 3.0's var keyword, I belonged to the group that worried about code getting unreadable. Now I've grown to realize that type information can be over-rated. Sometimes it is just irrelevant noise.

Extending the ArcGIS Javascript API

dorony — Sat, 08 Nov 2008 17:58:18 GMT

Working with the new Javascript API for ArcGIS Server 9.3, I am now writing quite a bit of javascript. If you try and write large amounts of javascript code (I would consider >200 lines as large enough) without using objects, soon enough you're going to have an unreadable nightmare in your hands.

In order for the code to be maintainable, I've realized I have to take advantage of dojo's object-orientation capabilities, and especially inheritance. This allows me to extend ESRI's default objects, compensate for missing behaviors, and add logic of my own. Luckily, in javascript the can't mark their objects sealed, or need to remember to mark methods as "virtual", so extending this API's objects is easier than doing so in the ADF.

For instance, suppose you want an ArcGISDynamicMapServiceLayer to tell you which layers are currently visible for it. Thing is, the API only exposes a setVisibleLayers method, but not a getVisibleLayers(). So let's try and add this, shall we?

 1 //doron.common.js
 2 dojo.require("esri.map");
 3       
 4       dojo.declare("Doron.ExtendedDynamicMapServiceLayer", esri.layers.ArcGISDynamicMapServiceLayer, {
 5         constructor: function () {
 6             dojo.connect(this, "onLoad", function () {
 7                 this._currentVisibleLayers = this._getDefaultVisibleLayers();          
 8             });
 9         },
10         setVisibleLayers: function(layers) {
11             this._currentVisibleLayers = layers;
12            //dojo's way of calling base method - so that default behavior is preserved
13             this.inherited(arguments);
14              
15         },
16         getCurrentVisibleLayers: function() {
17             return this._currentVisibleLayers;
18         },
19         _getDefaultVisibleLayers: function () {
20             var defaultVisibleLayers = [];
21             for (var i=0; i < this.layerInfos.length; i++) {
22                 if (this.layerInfos[i].defaultVisibility)
23                     defaultVisibleLayers.push(this.layerInfos[i].id);
24             }
25             return defaultVisibleLayers;
26         }
27       });

I am using dojo.declare to declare my new class, which inherits from esri.layers.ArcGISDynamicMapServiceLayer. My constructor first saves the layers that are visible by default in a field (this can only be done once the layer is loaded, so I'm registering myself to that event). I also override setVisibleLayers(), so that when it is called, I remember to update that field as well. Now I can easily expose the getCurrentVisbleLayers() method.

This class is something you can put in a .js file and reference everywhere you want - it is a much better approach than putting all your scripts inside the .html/.aspx/.whatever file.

A page that would use it, might look like this:

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html lang="en">
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
    <title>Dynamically Create Map Service Layer List</title>
    <link rel="stylesheet" type="text/css" href="http://serverapi.arcgisonline.com/jsapi/arcgis/1.1/js/dojo/dijit/themes/tundra/tundra.css">
    <script type="text/javascript" src="http://serverapi.arcgisonline.com/jsapi/arcgis/?v=1.1"></script>
     <script type="text/javascript" src="doron.common.js"></script>
    <script type="text/javascript">
      dojo.require("esri.map");
   function init() {
        map = new esri.Map("map");

        layer = new Doron.ExtendedDynamicMapServiceLayer("http://sampleserver1.arcgisonline.com/ArcGIS/rest/services/Specialty/ESRI_StatesCitiesRivers_USA/MapServer");
        
        map.addLayer(layer);
      }
      
      function showVisibleLayers() {
        alert( layer.getCurrentVisibleLayers().join(','));
      }
      dojo.addOnLoad(init);
    </script>
  </head>
  <body> 
    <div id="map" class="tundra" style="width:600px; height:400px; border:1px solid #000;"></div>
    <input type="button" onclick="showVisibleLayers()" value="Show Visible Layers" />
  </body>
</html>

Here I just took one of ESRI's samples, and replaced their class with mine. I also added a button that shows the layers that are currently visible. The reference to "doron.common.js" allows me to use my own class that overrides the ESRI one.

Hope this was helpful. If you know of any more ways to make life with the Javascript API more comfortable, feel free to share.

ArcGIS Server 9.3 Javascript API Impressions

dorony — Tue, 30 Sep 2008 08:50:00 GMT

After a long wait, I've finally been able to start using the new Javascript API that comes with ArcGIS Server 9.3. And the truth? It's pretty great.

It was difficult to start with, though. I didn't realize that the actual API (.js files and images mostly) doesn't come with the AGS installation discs - you have to request that separately. I have no idea why they won't just let you download an installation zip, as anyone is free to use the API via this link here. Our internal network doesn't have an Internet connection, and even if it did, I wouldn't want to rely on unneeded external resources in my application.

Well, I finally got the bits and "installed" them - and by that I mean followed the readme.html file that comes with the disc and tells you to copy this directory over there, and edit that .js file and that .CSS file. An installation script would have been in order, and now I have to create one myself, which I am too lazy to do, but I will. I promise.

Also, the installation doesn't come with an esri.debug.js file as is costumed with Javascript API's. The .js file is a "compiled" one, and is completely obfuscated and unreadable. Gosh, I can't understand ESRI's constant need to obfuscate everything they make. The Web ADF DLLs are also obfuscated, and the only ones they're hurting are the developers who use their product. If you still wish to be able to "step into" the ESRI scripts, I recommend that you use this website here to create your own esri.debug.js. It still won't be the clearest thing, as all the variables will still be 'meaningfully' named, but it is better than nothing.

Well, anyway, enough ranting, eh? Finally there's an API from ESRI that I rather like! You can produce with this mapping applications with code that is actually readable. Look at this sample (and view source) to see how easy it is to create a map with a toolbar. And the beauty is that it is easy even without a designer. I guess that since they couldn't rely on anyone using Javascript to use a designer, they had to make the code usable, and they got it right.

The outcome is that the code is a lot more extensible. It took me a few minutes to change this code to use the RadToolbar control. In the Web ADF, on the other hand, the controls are meant to use as-is (preferably with the cool-yet-kinda-silly "application builder" they have inside the manager application. Or at least the VS2005 designer). Therefore they are a lot less extensible. Yes, they give you more out of the box, like a TOC control. But it will cost you dearly to try to do something different. For this current application I have to build a dynamic TOC which can hold up to 200 layers, coming from different map objects, depending on the user. The prospect of making that work with the Web ADF is a bit daunting, but combining the js API and the REST services of ArcGIS 9.3 should make this a lot simpler.

So for now I am rather pleased. Things behave as they should - there aren't many surprises and heads banging on desks. I am a bit concerned about writing more Javascript - we are still at VS 2005, so no intellisense for us, and a heavy reliance on the documentation (which is pretty good, by the way). Another concern is the usage of another Javascript library - Dojo. We are already using ASP.NET Ajax (the RAD controls use this as well), and now adding Dojo and ESRI's own .js files, and maybe even JQuery I've been hearing a lot about - this is going to make for a big download to our clients. It does seem pretty weird that ESRI is using ASP.NET Ajax for the new .NET ADF controls, and Dojo for the Javascript API. Oh well.

To summarize, I would say ESRI has a winner with the new REST + Javascript combination. I doubt that I would now bother with anything that has ADF in its namespace - I'm guessing I would use the Javascript API for the client side, and open a direct ServerContext if I need to do something on the server. I'll keep you posted on how this worked for me.

Shana Tova!

StackOverFlow.com is Open, and it's Great

dorony — Mon, 15 Sep 2008 19:09:00 GMT

If you haven't heard about it, Stack Overflow is the new baby of Jeff Atwood and Joel Spolsky. The concept is as simple as it can be: creating the most massive programming FAQ in the world. Questions are asked, answers are given, and the best answers appear on top.

I was in the private beta of this site, and I can be a witness that this works really well. Never was there a forum or a newsgroup in which I asked a question about programming and received good answers so quickly. Also: the simple-yet-clever UI of Stack Overflow can teach all a meaningful lesson. This is how web-sites should be built.

The public beta has launched today, so go ahead and give it a try.

Wanted: A Usable Installer Technology

dorony — Sun, 10 Aug 2008 19:28:00 GMT

On Friday I was at the Israeli Alt.NET conference, which was great. One thing that kept coming up was the frustration of everyone with current Installers technologies. I am using Visual Studio Setup Project, which is rather usable, but has many disadvantages, with the main one being the lack of ability to build it outside of Visual Studio.

I've also tried using WiX, but its XML "UI" and incredible learning curve left me a bit puzzled. The Alt.NET guys assured me that I wasn't the only one. They also bitched about Installshield and other technologies.

At the conference I also heard about FinalBuilder for the first time. This is a popular software that allows you to create a powerful build script using a very simple GUI. You can choose from all manner of tasks, such as creating a web-site in IIS, or setting up a virtual PC.

And my point is this: Using FinalBuilder's trial for the first time made me think - this is exactly what I would look for in a software that let me create installation scripts. Picking tasks such as "Update web site authentication in IIS" or "register to GAC" and putting them in a nice list. From that I could get a working MSI.

If someone went ahead and made this "FinalInstaller", I'm sure he would enjoy a nice income. Go for it, startup guys.

WPF Designer/Developer Paradigm - Does It Really Work?

dorony — Tue, 05 Aug 2008 11:54:57 GMT

All the WPF presentations I've seen made a big deal about how this technology allows you to separate the work of the designer and the developer. The designer can go about, designing away with the Expression tools, crafting a XAML file. Then the developer can add C# logic to the relevant CS file.

When I actually tried to do something with WPF, it immediately seemed suspicious to me. XAML, apparently, is also code. Not only that, it is also tightly coupled to the accompanying "code-behind". There seem to be some things that you just can't do with XAML - and I'm talking about visuals - like making a video resize correctly. Anyway, while coding I kept going back and forth between the XAML and the code until I got the result I wished for.

Now, I'd be the first to admit that I'm not WPF pro, but I do have experience with ASP.NET, and it is the same way there - It is good to have a separation between display code and behavioral code, but I just don't think that it would ever work if someone handed me an ".aspx" file and told me to "just add my code to that".

I think that it might work if the developer and the designer worked together (i.e. same desktop) on creating a window. Or if the designer works only on very limited things, such as control templates and styles. But coding a complete XAML for a window with Expression and passing it on to the developer? I doubt that the latter will be able to read the damn thing, let alone work with it.

Then again, I might be wrong. I really have no idea, as I don't know anyone who works with WPF on a daily basis and has a designer in his team. Just had an itch to talk about this.

Design Patterns - The Fun Way

dorony — Sat, 19 Jul 2008 19:17:15 GMT

Anyone who's ever tried to read the traditional GoF design patterns book, or any other book on the subject for that matter, has probably been bored to death. This is sad, since there is a lot of smarts in these patterns that people have already thought of for us, and using them - when appropriate - should really become a second nature to every programmer.

No worry, though, since I will now tell you the best possible way to learn about the classic design patterns, and that is to read Head First Design Patterns. I am now reading this book, which I borrowed from a friend, and it is really a joy to go through. With clear examples, lots of humor and a whole bunch of drawings and pictures - the "head first" way of teaching really seem to work.

You really have to read this to understand, but when a book contains, for example, sessions of two patterns that are being interviewed by a talk-show host, you can see that something special is going on. The authors have gone out of their way to find the best way to get each piece of knowledge into your head and make you remember it.

The only disadvantage of this book that I could find is that all the examples are in Java. It's not much of an issue, except in chapters such as the one about the Observer pattern, where mentioning the way C#'s events implement this seems mandatory to me.

Nevertheless, if you're going to buy a single design patterns book - this should be it. I'm definitely going to have all the programmers in my team read it.

Why I Like My Job

dorony — Fri, 27 Jun 2008 18:14:45 GMT

Recently I've been reflecting on my life's choices. Just a reflective kind of mood, I guess. I chose to become a programmer when I was 18 years old. That was 6.5 years ago, and a pretty young age to make life-changing choices - at least in my country. That choice pretty much set the course for me for the next 9 years, as I was going to study in the university for 3 years and then work in the same place for the following 6 years. That's a lot of burden on 18-year old shoulders.

So I got to thinking - if I had to make the same decision again, would I choose the same way?

And what I answered myself was - Hell yeah! I love being a programmer, and the main reasons are:

It's challenging work. I get to use my brain to solve problems.
I get to create stuff. At first there is nothing, but after some creation there is something that people can use, and it makes their life easier. Well, most of the time.
I'm no artist, and can barely draw an image of a person without him looking like he just fled Chernobyl, but after writing software I can sometimes look at it and say: "Hey, I just made something pretty".
I get to work with some really smart people, and learn from them.
I get to learn so much about myself, as a person. Debugging one of these random-looking bugs can really tell you what you're made of.
The pay isn't bad.
I'm pretty good at it, or so I'd like to think.

It's hard work, but I guess I wouldn't have it any other way. I can't really think of anything else I would have preferred to do. I like to write, but I don't think I could have done it full-time as a reporter. Blogging pretty much scratches that itch for me.

Speaking of scratching itches, if only I could write some software that killed all mosquitos, I'd be a much happier person now. Probably richer too. The bastards are driving me crazy.

Visual Studio Setup Project Annoyance

dorony — Wed, 04 Jun 2008 17:18:15 GMT

Lately I've become uncomfortable with the setup project that comes with Visual Studio 2005. We've been using it to deploy a web application and a windows service, and we hit all sorts of snags.

For instance:

You can only build it inside Visual Studio, so our build server can't produce MSI's for us.
You can't attach .bat files to the installation actions, only .vbs files. I really can't understand why.
CustomAction parameters syntax is not the prettiest thing.

But our latest issue with the setup project had me really puzzled for a while. It involved the deployment of the windows service I mentioned - specifically, its app.config. For some reason, the setup project regarded the actual app.config file as that project's output, instead of the service.exe.config that is generated by MsBuild. In order to deploy that service to different environments we change the .exe.config according to the current build configuration, by using an MsBuild task called XmlMassUpdate. We change the .exe.config file directly, not the app.config, since the latter is usually protected by source control, and therefore marked as read-only. Anyway, it makes a lot of sense for us to change only the output the build produces and not the source.

Thing is, you can't change the setup project view of what the output is (at least we couldn't find a way to do this, even by manually editing the project file), and since it decided that app.config is it, it left us with no choice but to change that source file directly.

I really think the output should simply be regarded as the entire /bin/debug or /bin/release directories, and not just the .exe + app.config files. Go figure.

Using UpdatePanel to Disable GridView View State

dorony — Fri, 23 May 2008 17:07:31 GMT

View state. We usually hate it and love it at the same time. It's definitely a creature of comfort: having our controls automatically maintaining state is definitely a useful thing. But it can also be quite hazardous to your page performance - especially when used with a GridView that has many rows. This big-ass hidden field that gets generated is sure to make your users' round-trips quite a pain. And so the million dollar question is...

How do I disable view state and stay alive?

When you go ahead and mark that GridView of yours with EnableViewState="false" you'll notice that you now have to bind to your DataGrid's DataSource on every post-back. Otherwise, how would it know what rows to render? You have to do it, since the entire page is rendered on each and every post-back. And so you need to get those rows back from the Database even though nothing has changed (sure, you can use caching to eliminate this cost, but caching is not always easy to achieve).

But, if you use an UpdatePanel correctly, you can re-render the grid only when it changes, and still leave the view state off. Let's see how we can achieve this. Here's our page markup and code behind:

<form id="form1" runat="server">
    <asp:TextBox ID="FirstName" runat="server"/>
    <asp:TextBox ID="LastName" runat="server"/>
    <asp:Button ID="AddPerson" runat="server" Text="Add" OnClick="AddPerson_Click" />
 
    <asp:GridView runat="server" ID="PeopleGrid">
    </asp:GridView>
  </form>

public partial class PeoplePage : System.Web.UI.Page 
{
    private PeopleRepository _peopleRepository =  new PeopleRepository();
 
    protected void Page_Load(object sender, EventArgs e)
    {
       if (!Page.IsPostBack)
       {
           BindGrid();
       }
    }
 
    protected void AddPerson_Click(object sender, EventArgs e)
    {
        _peopleRepository.Add(new Person(FirstName.Text, LastName.Text));
        BindGrid();
    }
 
    private void BindGrid()
    {
        PeopleGrid.DataSource = _peopleRepository.GetAll();
        PeopleGrid.DataBind();
    }
}

All is nice and simple: we have a grid, and two text boxes that allow us to add a person to the grid. Note that we only access the data source once on the very first page-load, and whenever we add a new person. Not on every post-back.

Now, if we wanted to turn view-state off, we'd have to make a few changes. This is how our markup will now look like:

<form id="form1" runat="server">
  <asp:ScriptManager ID="ScriptManager1" runat="server" />
  <asp:UpdatePanel ChildrenAsTriggers="false" UpdateMode="Conditional" runat="server" ID="PeoplePanel">
    <ContentTemplate>
      <asp:TextBox ID="FirstName" runat="server"/>
      <asp:TextBox ID="LastName" runat="server"/>
      <asp:Button ID="AddPerson" runat="server" Text="Add" OnClick="AddPerson_Click" />
      <asp:GridView runat="server" ID="PeopleGrid" EnableViewState="false">
      </asp:GridView>
    </ContentTemplate>
  </asp:UpdatePanel>
 </form>

There are a few things to note here. We've added an UpdatePanel, and we changed its UpdateMode to Conditional and its ChildrenAsTriggers property to false. I am doing this in order to manually control exactly when the UpdatePanel gets updated. Since, as you can see, I've turned off the view-state for the grid, I only want it to be updated after the grid was bound - In any other case the grid will be completely empty, since without view-state it can't automatically recover its state.

So when does the UpdatePanel get updated? When we tell it to. Let's change the BindGrid private method.

private void BindGrid()
{
    PeopleGrid.DataSource = _peopleRepository.GetAll();
    PeopleGrid.DataBind();
    PeoplePanel.Update();
}

Note how we manually update the panel whenever we update the grid. The rest of the code is left unchanged. By making sure the update panel is only updated when grid is re-bound, we'll always have rows in our grid, even though view-state is off. This method works beautifully when you have a page with several un-related GridViews. You can turn off view-state for them all, and only update what you need, when you need it.

So, to recap, if you want to turn off view-state for your grid, you need to follow these steps:

Put an UpdatePanel around the grid, make sure you set UpdateMode to Conditional and its ChildrenAsTriggers property to false.
Make sure you manually call the Update method of the UpdatePanel every time you bind the grid to the data, and only then.
Set the EnableViewState property on your grid to false, and enjoy the improved performance!

This way, any post-back that you have on the page that doesn't change the grid will not upload a huge view-state field, and it won't require you hit the data-source again. Also, less data is sent back to the client.

Of course, if you have inline editing in your grid, this is not going to work very well for you, as you'll probably need the state for each row the user edits. The solution for that, is, well... Don't use inline editing. It's not good for you.

If you want to have a look at the entire example code, you can grab it right here.

Ajax Page Methods Will Always Have Session

dorony — Tue, 06 May 2008 17:54:31 GMT

In my ongoing process of performance optimization, I noticed the use of an ASP.NET Ajax Page Method in a certain page. It looked something like this:

[WebMethod(true)]
public static bool HasDataBeenUpdated(DateTime lastUpdateTime)
{
   //Checks something in the cache against this date
   //....
}

Page methods are a way to Ajax-ly call a static method on the page, instead of creating a specific web-service for this. As you can see, this method was marked with [WebMethod(true)]. This property is usually used in web services, but ASP.NET Ajax employs it for page-methods as well (it is rather the same thing). The constructor we used for this attribute is defined like this:

public WebMethodAttribute (
   bool enableSession
)

That means that passing true will cause ASP.NET to load the Session for this request, making it more costly. I noticed that the HasDataBeenUpdated method can be changed so it won't need the Session. Since it was being called every 5 seconds from the client, it had to be very efficient. I made the change, and was able to turn off Session by using [WebMethod(false)]. Thing is, it didn't really get turned off. The request was still slower than it should have been. Apparently, if you use a page-method, Session will be loaded even if you explicitly pass false to the enableSession parameter.

The documentation doesn't mention this, but the example there is about Session access, so that should have probably tipped me off. This issue seems rather weird to me. I understand that maybe the defaults should change (web-services methods default to no-session) when you write [WebMethod] and nothing else. Maybe. But since I'm explicitly asking for no-Session mode, the result is surprising.

Personally, I think that if they wanted page-methods to behave differently from web-service methods, they should have used a different attribute for it. Anyway, the solution is simple: I ended up moving the method to an .asmx web-service and calling it instead.