Tony Lombardo

Hacking Web Services; Security and Telnet

2009-10-29T16:22:47Z

If you’ve built a web application in ASP.NET chances are you’ve also consumed or even created your own web service. Web services are an easy way to share data, and even commit actions across technology lines. I recently ran into an application that used a web service that captured my curiosity – enough so that I thought I would share my experience.

The app was a game, and at the end of the game a message popped up that said - “reporting information”. Interesting, I though. It was a Silverlight application, which meant the xap file could be downloaded and dissected, which is precisely what I did. A quick look at the .xap file and I had a config file which gave me a service location. In other words, I now had the endpoint of the web service.

Microsoft makes web services cake (yellow cake with chocolate frosting to be precise), and web services by default have an auto-documentation feature enabled which will show usage scenarios and parameter information when viewed through a web browser (HTTP GET). This is also an easy way for a curious mind to find out just exactly what a web service can do. So my next step was to navigate my browser to the web service URL. And BINGO! I had a list of all actions the web service could support, including the HTTP POST stubs for calling the web service.

BTW, if you don’t want ASP.NET to automatically generate this documentation (including the more formal WSDL), you need to remove the “documentation” protocol from the webSerivces section of your web.config. Code below, simply paste it into your web.config or machine.config file.

          1: <webServices>

         2:     <protocols>

         3:         <remove name="Documentation"/> 

         4:     </protocols>

         5: </webServices>

If you’re building a public SDK and encourage others to call your web service, you’ll want to leave this documentation feature up. But if you’ve built a web service for your LOB application, and don’t really want others to know about it.. turn off the auto documentation.

Once I knew the service URL, I could have gone into Visual Studio and wrote a quick app that consumed the web service (add web reference…) but I decided to go the more fun route – Telnet. It had been a while since I used Telnet, and I quickly found out that Telnet isn’t installed by default on a Windows 7 or Windows Vista machine. But that’s quickly solved by going into add/remove programs, and choosing windows components –> Telnet.

Why did I choose Telnet? Well, because the web service documentation so kindly provided me with the exact HTTP POST information that I needed to call the service. If you’ve never done a manual HTTP POST through Telnet, it’s time you tried. It’s relatively easy, and a rewarding experience.

Telnet is a command line application, that connects to any port you tell it to. In my case, I wanted to connect to port 80 (http). I’ve also used Telnet in the past to send SMTP messages (yes, email...) When running Telnet, you specify the port after the domain. Remember, you have to use the domain when connecting, not the entire URL. For example, if you wanted to go to http://mydomain.com/services/myservice.asmx you would do something like

    telnet mydomain.com 80

You’ll use the rest of the URL when you execute your POST command. This is low level HTTP right here, and it’s a great way to better understand what’s happening behind the scenes when you click buttons and fill out checkboxes in your favorite web browser.

Here’s what you would see from the auto documentatoin on the fake myservice.asmx web service (http://mydomain.com/myservice.asmx):

       1: POST /services/myservice.asmx HTTP/1.1

       2: Host: mydomain.com

       3: Content-Type: text/xml; charset=utf-8

       4: Content-Length: length

       5: SOAPAction: "http://mydomain.com/services/HelloWorld"

       6:  

       7: <?xml version="1.0" encoding="utf-8"?>

       8: <soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">

       9:   <soap:Body>

      10:     <HelloWorld xmlns="http://mydomain.com/services/">

      11:       <name>string</name>

      12:     </HelloWorld>

      13:   </soap:Body>

      14: </soap:Envelope>

There are a couple of things you’ll need to change in the text above to successfully call this service. First, you’ll want to set the value for the parameter (<name>string</name>). By default the documentation will put values in there that don’t make sense, in this case “string”. Once you have the soap:Body information completed, you need to calculate the size of the data portion, which is the length of the entire XML fragment (lines 7-14 above). You can either count the characters by hand, or you can paste the XML into MS Word, and use the Word Count feature to show how many characters (including spaces) you have. Once you have the length, update your Content-Length value (line 4 above).

Calling this web service from a command line using Telnet is pretty basic once you have the text all ready. You’ll want to paste in the top portion of the text (lines 1-5 above) then hit the return key 2 times. The first time is to end the SOAPAction header, the second is to end the headers section of the POST (and begin the data section). At this point, it’s time to enter the POST data, which is lines 7-14 above, followed by another enter key. Once you hit the enter key you’ll receive the response from the web service. If it’s an HTTP 200, you know it was successful, otherwise there was a problem with your post. I was unsuccessful the first few times I tried, because I pasted in the complete text you see above (lines 1-14). It seems that Telnet doesn’t like the way this text is formatted. I’m guessing it’s a difference in the new line character that’s used. Anyway, the trick (if you’re using copy/paste) is to paste in the headers, hit return twice, and then paste in the body.

Aside from feeling cool because you just called a web service from about the lowest practical level, this exercise should open up your mind about web services and security. For starters, if you put a web service out there, you should expect that others are going to call it, and not necessarily the way you intended. In the case that started all of this, data was being stored that I had created through the application. But I didn’t like the data that was created through the application, I wanted to send my own data. Much like securing a web application, you should not expect that your web service call will always be coming from your application! This is a classic example of why client-side validation in a web page is not a security feature, though it is certainly a usability feature. You can’t prevent a user from submitting data on the client side. If they really wanted to post values that you’re UI is preventing, they can always turn to Telnet, other another HTTP utility.

Here’s one last trick for you. Open up an HTTP Listener like Fiddler2, and run the application that’s calling a web service. If you take a look at the activity that Fiddler has captured, you’ll see an HTTP POST to the web service URL. Fiddler even has a ‘RAW’ view, where you can get the precise data to post, just like we pulled out of the web service documentation earlier. In this case, you’re seeing exactly what was posted to the server. I mention this because you may think, “well if I don’t store my web service URL in the config, no one will ever know where it is and I’ll be safe!”, and you would be wrong. It also highlights that when you’re not using a secure web service, or SSL on a web application, the data is TRANSPARENT! Anyone plugged in downstream from you with an ethernet sniffer can see exactly what is being transmitted, in clear text. Luckily, there are secure ways of calling web services. If your service is capable of making changes to data, or gives the caller access to potentially private data, you should certainly secure your web service.

If you want to learn more about securing your web services, you can read about this topic on MSDN http://msdn.microsoft.com/en-us/library/aa529262.aspx

Can’t Touch This

2009-10-26T17:21:14Z

Touch seems to be the latest craze in software, but astonishingly, it’s nothing new. Most applications out there will work perfectly well in a single touch emulated environment. Basically, a hardware device turns your finger touch into a mouse action. Yet, even though those interfaces and devices have been around for years, it really wasn’t until the iPhone, that people got reacquainted with touch. Here’s the reason why.

Touch vs. Multi-Touch

Touch in and of itself is pretty basic. Take a finger or a stylus, and use it to drive the mouse subsystem. While this type of touch is better than no touch at all, it didn’t do anything special enough to get a user to go from using a mouse, to using their finger. Then multi-touch came around. Suddenly, you could do things that would have been difficult or impossible with a classic mouse device.

Zooming with two fingers is now a classic example, and sadly one of the only examples out there. The reason for the lack of multi-touch interfaces is actually quite simple. Multi-touch isn’t easy to do, and more importantly, coming up with scenarios where multi-touch is beneficial in an application is a challenging task that requires more of a designer’s brain, than a developers brain.

And here’s where it always gets disappointing. Lack of applications that use the hardware mean the hardware isn’t in demand, which means the price of the hardware will remain high, which then curbs the demand for applications that use multi-touch. And the cycle continues. But the numbers are growing, and we’re getting closer to critical mass. Businesses are starting to understand the value of an extremely usable, fluid interface with multi-touch. As businesses start to invest in these technologies, hardware prices will drop, and everything else will hopefully fall in line.

In the meantime, developers need to start getting used to the idea of building a touch interface. If you’re a Silverlight developer, and want to get a quick start – take a look at Tim Heuer’s blog http://timheuer.com/blog/archive/2009/07/30/silverlight-3-multi-touch-introduction-fundamentals-basics.aspx

Start playing around with the idea of using Touch events, and adding an extra layer of functionality to your application. I’m tired of not having touch capabilities on my computer, and I’m ready to do something about it! I’m not sure if Windows 7 will be the catalyst that ignites the multi-touch fire, but I sure hope it is.

Silverlight UX: Sum Of The Parts

2009-06-30T20:09:18Z

When talking about Silverlight, it is only natural to compare it to standard web based applications (ASP.NET, PHP, JSF, etc.). Silverlight has some clear advantages when dealing with large quantities of data, or speed and performance in say grid operations, but there’s another aspect of Silverlight that may be hard to notice at first. It’s the ‘little’ things. I call them little, because alone, each of these features isn’t something that will shock or amaze you. But combined, these features create a User Experience that is specific to Silverlight. Let’s take a look at a few examples.

Above is the Infragistics XamWebGrid in GroupBy mode. The part to notice is the small x that shows up when you mouse over the Group indicator. It makes it easy for a user to figure out how to ungroup the data, and that’s just the start. Notice the shape of the Group indicator? When you group by multiple columns, these fit together like puzzle pieces. Again, indicating to the user exactly what’s happening as shown below.

The differences are very subtle, like a glow animation when you mouse over a button; the same type of differences you see between Windows Forms and WPF. But these subtle differences can create a totally different experience for a user. The application feels more alive, and when these features are put to good use, like in the example above, the UX of the application can be improved. And here I thought storyboards and animations were only used for 3D rotating textboxes with movies playing in the background..

The Chains that Hold Us Back

2009-06-29T19:33:02Z

I’m not sure there’s ever been quite as much activity in the world of Web development as in the past couple of years. The browser ‘wars’ have been re-ignited, and technology is advancing at a frantic pace. It’s almost too much to keep up with. Right now as a web developer you have Silverlight 2 at your disposal, and a beta of Silverlight 3, with talks of Silverlight 4 already taking place. Then there’s the CSS 3 specs, HTML 5 specs.. it’s almost too much to comprehend. I guess we’re lucky in a way, that there are currently significant barriers keeping us from these technologies.

Let’s take a look at Silverlight first. With clear advantages in performance and usability over standard HTML/JavaScript, Silverlight looked like a definite winner for many web applications. But Silverlight suffers from one big disadvantage – the plugin that needs to be installed. That simple plugin which only takes a minute to install, is preventing widespread adoption of Silverlight across corporate America. As with any new software, IT must first test Silverlight on their systems, and then come up with a rollout plan which as many of you know, is not something that happens overnight. So even with 3 versions of Silverlight in 1 year, many developers are just now getting the nod from corporate to start discussing the option of using Silverlight.

CSS3 and HTML5 promise to change web development (in a good way), but are both being held back by standards committees and browser support (or lack there of). In all likelihood browsers will implement the features of these specs before the specs are actually complete. But even the implementation will likely happen at different rates for each browser. The reason most of us write web applications in the first place is so that one page can be viewed in any browser on any computer by any user. Which brings us back to IT, the guys who will inevitably be forced to hold back the latest versions of these browsers from being installed, so that they can be properly tested and a deployment strategy can be planned.

While all of these new technologies promise to revolutionize web development, it’s unlikely the revolution will happen as quickly as any of us would like to see. IE6 is still the corporate standard browser in many organizations. The good news for developers is that it gives you extra time to learn the new technologies. And if there’s one thing I know, it’s that you can accelerate rollouts if you prove a valid business case. Show the IT director a prototype of the app you just put together using Silverlight 3 that took you half the time to write and solved the UX and Performance problems of the current html based application, and a Silverlight rollout is likely to be around the corner.

Visual Designer : A Developer’s BFF

2009-06-26T16:21:16Z

Developers are often cast into a group and stereotyped as "visual design challenged”. The fact is, a true Visual Designer picks colors and creates designs for applications that make my attempts look like grade school arts and crafts project. But that doesn’t mean developer’s don’t care about design. Actually, I think most developers put a tremendous effort into trying to make their applications look good. It’s just that the results aren’t always award winning..

I used to get insulted when people would mention that developers weren’t good at styling applications. From the first day I started coding, I was the only one working on my applications. The application was my creation, and I was responsible for every aspect of it, including the design. By hearing generalized statements about how developers are bad at visual design, it was like telling me that I don’t have the entire skills I need to build a successful application.

Luckily, I’ve grown up a little since then. While I still don’t like hearing I’m not good at something, I can certainly respect that there are professionals in the visual design world who can do a much better job of making my applications look good. I can spend 2 years writing the most beautiful code, but at the end of the day, the user only sees the User Interface. UX is perhaps the most important aspect of an application, because it encompasses all aspects of the application. If the code was buggy, the UX will be poor. But more importantly, if the code was perfect and the UI design was not, the UX will be sub-par. Want proof of just how important the UI/UX is? Take a look at Facebook vs. MySpace.

MySpace was the clear favorite two years ago, so what happened? The MySpace page was ugly by default, and users could do anything they wanted to make it even uglier. Sure, customizing your page sounds like a good idea, until you realize that you’re not that good at it. Facebook took a different approach – a fixed UI that looked good out of the box. Facebook users didn’t need to spend time making their page look good, and more importantly, you didn’t have to look at hundreds of other bad looking sites. Take another example, the iPhone. Apple cares about it’s image so much, that all iPhone applications need to follow design guidelines, and must be approved before they can be made available to iPhone customers. Still not sold on the importance of UI? Remember geocities? How could you not. An entire domain of horrendous designs. The negative experience associated with those bad designs is something that sticks with you. I don’t remember if I ever found anything functional on geocities, I’m sure I did. But that’s not what I remember. I remember the horrible color choices, images with choppy edges (that of course weren’t transparent), and JavaScript errors.

There’s a point in here somewhere. Oh yeah – designers are a developers best friend. Designers make developers look better. After I spent 2 years on a project, of course I want people to think it’s the coolest thing they ever saw. But my late nights of coding are essentially going to be judged on how good the application looks, not how well I wrote the code. I remember the days of getting beta feedback like, “It’s not colorful enough, can you add some color to it?” I would go back to my desk, bummed that no one shared the same excitement as I did that the project was complete. But in actuality, it wasn’t complete. It was functional, but that doesn’t make an application “done”. So, I’d go back to my desk and throw a few different colors around the application (usually different shades of blue) and try again. I spent weeks just experimenting with different colors to see if I could produce something a *slightly* more visually appealing. Weeks that I could have spent on my next project. I certainly don’t miss those days. Today, visual designers take the code that I wrote, and bring it to life, and they do it in far less time than I ever could have, with far better results. They might hand me back a wireframe or a mock-up that I need to convert to code, or if I’m lucky, they’re just modifying the XAML or CSS directly for me. And when I hear comments about how cool an application is, I know that without my code, that would have been nothing more than a static image. I bring designs to life, designers bring my code to life. It’s amazing that I ever did both the design and development. And it’s even more amazing that I resisted change at first.

MVC vs. WebForms, A Clear Loser Emerging

2009-06-23T20:03:34Z

Working with WebControls and WebForms for the past 8 years has taught me a lot about web development. The one thing that I learned above everything is that the onus is on the developer to write good code. Now that may not sound like something revolutionary, but the fact is that ASP.NET WebForms makes building web applications easy by abstracting away some of the difficulties of a stateless protocol. And it also makes it easy to forget about what’s actually happening behind the scenes to make everything possible. Does that mean WebForms is flawed? No.

MVC offers a fix for some of the problems that WebForms has been plagued with. Problems like bloated ViewState, and that ‘pesky postback model.’ On the surface, this looks like an attractive solution for every web developer out there. A promise to get rid of ViewState – a web application’s mortal enemy? It has to be good. That is until the application your building needs some sort of state mechanism, and you begin re-inventing the wheel. I think it would have been much easier just to go back to you WebForms application and disable ViewState.

The problem right now is that there is so much focus over why MVC is better than WebForms, that everyone is forgetting a basic rule of software development: use the right tool for the job. I’ve said it dozens of times, MVC has a set of scenarios that it first very nicely, as does WebForms. One platform does not need to be declared a winner – they’re two equals that should be placed into your metaphorical toolbox. So who is actually losing right now? The developer community that is caught in the middle of this faux war. Developers who think that they have to move to MVC out of pride or fear that WebForms will be replaced by MVC. Developers who are only hearing one side of the story right now at local community events and tradeshows because let’s face it.. WebForms isn’t sexy anymore at 8 years old. Ironically, this same issue of “sexy talks” was discussed last week at NDC with Scott Hanselman behind the camera.

Conferences aren’t picking talks about “the old stuff”, because they’d rather focus on what’s new. New is sexier, and conferences are all about attendance numbers. But here’s what these conferences don’t seem to understand – every day there’s a new developer joining the community who needs to start from zero. Developers gauge what’s important by what’s being talked about, it’s why we have trends and tag clouds. It’s human nature. If I hear 100 people talking about a subject, it must be important. Right now I hear 100 people talking about MVC, and no one talking about WebForms, so I guess MVC is more important, right? That’s the type of thinking happening right now, and it’s nothing new.

“MVC brings web development back into ASP.NET”, is one of the most common arguments I hear for its use. Yet the whole reason for WebForms existence was to free you of the dirty details of building a web application, and let you focus on your business logic. To give you a set of functionality to be able to build on top of, the same focus for every library and framework out there. It’s why you don’t have to write browser specific JavaScript when using jQuery or ASP.NET AJAX, and it’s the reason we don’t still program in machine language. Can I write a tighter loop in assembly than I can in JavaScript? Sure. But for the applications I’m writing that’s not going to be an issue. Maybe I’m writing an application where performance is the top and only concern. Now writing the application in assembly doesn’t sound like a crazy idea. If my requirements were to build a spreadsheet like application that offers filtering, copy and paste and exporting to excel, I’m going to jump to WebForms. That’s the whole point behind using the right tools for the job.

I read a blog post today that talked about how you should dump WebForms and go with MVC as soon as possible, so you can get back to web development roots. The argument just didn’t make sense to me. It’s like asking me to stop coding in C# and move to C++ because C# developers just don’t understand pointers and memory allocation.

So here’s my call to action. Rather than talking about why one framework or platform is better than the other, start discussing when one is better than the other. What scenarios is MVC geared for? When would you use WebForms (MVP) instead?

The best advice I’ve seen so far is that WebForms is the platform of choice for building web applications, where MVC is more suited to building web sites. This is still a bit abstract since there’s no clear definition of web applications, but I think it’s safe to say that if you’re building a web version of a win client application, you’re building a web application. If you have a ‘grid’ in your page for purposes above that of just layout, you’re building a web application.

ASP.NET 4.0 & Why it Matters

2009-06-08T22:09:53Z

I hear a lot of overused and overloaded terms these days like “leaky abstraction” when talking about WebForms. As people repeat these items like robot drones, I wonder if they truly understand what it means, and more importantly how it affects a developers ability to build software. But whether it’s a group of robot drones, or an increasing number of well educated software engineers, we’ll leave for the subject of another debate. Back to the matter at hand. Of all of the WebForms complaints, it usually boils down to a few key issues – ViewState, ID generation and HTML Markup & Postbacks; each of which is undergoing changes in ASP.NET 4.0.

ViewState

To understand the first issue of ViewState, you have to understand the ViewState model. It works recursively in nature, with each control responsible for initiating the loading and saving of ViewState from it’s child controls. The problem comes when you turn off ViewState at a root level. Since the parent control is no longer storing ViewState, it’s child controls get ignored. Basically, you can turn ViewState off selectively for children, but you can’t turn it on selectively if it’s disabled for the parent control. The solution? ASP.NET 4.0 introduces the ViewStateMode pattern which is separate from the EnableViewState property. ViewStateMode has 3 values, Enabled, Disabled and Inherit (the default). When ViewStateMode is set to disabled, any child control that is set to Disabled or Inherit will have it’s ViewState turned off. If a parent control has ViewStateMode=Disabled, and the child control has ViewStateMode=Enabled (the important new scenario), the child control will still have it’s ViewState saved. This in essence, is what the feature is all about. The net gain for a Web developer is a lighter weight page, because you now have the ability to turn off ViewState in places that you didn’t really need it on in the first place.

ID generation

Have you ever taken a look at the html markup produced by an ASP.NET WebForms application? I have. Actually, I spend a good portion of my time examining html markup and discerning how a page can be made lighter or faster based on what I see. One of the big offenders happens to be ID strings. If you want to address an element, you need to give it an ID. If you want to address it uniquely, you need to come up with a mechanism to make that ID unique. In ASP.NET WebForms this was done by pre-pending the parent control’s id to the ID string of a control. The problem is that as applications became more complex, so did the control hierarchies, which then caused UniqueID and ClientID strings to become unmanageable. Looking at an application today, it’s not out of the question to see something like “contentPlaceHolder1:ctl0:ctl0:UpdatePanel1:Panel1:GridView1” Now if you use that string a few times to address id’s or create css class names, you’re bloating your HTML. Even worse, you’re creating a recipe for cascading failures if you ever change the containership or the ID of one of the parent controls. Suddenly, your element’s ClientID has changed, and you need to go through and update your code.

In ASP.NET 4.0, you’ll have the ability to set the ClientIdMode to “Static” which solves most of these problems. With a Static ClientIdMode, the ID string you set for the control, is the same string that will be used for the ClientID. This has the benefit of being less fragile, and gives you the ability to clean up your markup by shortening ID’s considerably. The drawback to using ClientIdMode=Static is that ID’s will not be ensured to be Unique by the framework, making this a manual task for the developer. Not sure about you, but if that’s the biggest challenge of my day, I’ll be smiling.

HTML Markup & Postbacks

Postbacks were the bread and butter of ASP.NET 1.0. Luckily ASP.NET has come a long way since then, and developers today understand that creating a good User Experience means limiting postbacks. The amount of HTML rendered to the client also has a direct correlation on User Experience. The more HTML/Markup, the longer a page will take to load. ASP.NET 4.0 improves this key scenario by adding Client-Side DataBinding and templating. Think of client-side templates as a repeater that get’s populated by JavaScript. Why populate the repeater on the client-side rather than the server-side? It’s a matter of multiplication. Take the same 4 lines of HTML in a repeater template and multiply it by the number of items in your datasource. Now push all of that HTML down over the wire to the client. Make matters even more interesting, use the same datasource to populate a grid. In a typical scenario, you’re pushing the same data down two times, once for the repeater, once for the grid. If you had that data available as a client-side DataSource, you only send the data down once, and re-use it on multiple controls. At the price of a little extra processing power to create the dom elements through JavaScript, you get the benefit of possibly drastically reduced HTML markup, and free yourself from relying on Postbacks in order to populate a list.

The three features listed above are just a short list taken from the ASP.NET 4.0 features whitepaper. Even in this short list, it’s easy to see that ASP.NET 4.0 is changing the face of WebForms. Many of the concerns that developers have expressed and many of the advantages that MVC touts over WebForms are being addressed. The point is, WebForms isn’t dead, it’s quite the opposite.

Surveys, Polls, Voting, and why they usually stink

2009-05-28T21:28:45Z

I’ve never been a big fan of surveys or polls. Not because I don’t like them, but because I always disagree with their validity and the conclusions that are drawn from the results. Lets take a look at a couple of examples. Readers Choice awards were recently handed out. I received an email from a customer who wanted to let me know that he was contacted by a component vendor to go out and vote for them, and he didn’t even own their product. To my surprise, he wanted to know where the Infragistics email was. My answer – we make a very conscious effort to limit the number of emails we send out to our customer base. At the end of the day, our decision to keep spam out of our customer’s inboxes also meant that we were at a disadvantage in the survey/poll/award. Does the poll actually show which product is the best? Or does it show who spent more time and energy on campaigning for votes?

Now let’s look at case #2. There’s a survey out right now asking questions about AJAX tools and frameworks, and which ones developers are using. I don’t know exactly what the results of this survey look like, but here were my first impressions. The survey is hosted on a personal blog, where most readers likely share similar interests. Simone Chiaretta (the blogger) respectfully acknowledges that this blog has a limited audience and is likely biased toward the ALT.NET kind of developer. I’m sure Simone has the best intentions about publishing the survey, but it will be very difficult to not get a skewed response. In addition, what does the response actually mean?

A current snapshot of results shows that 76% of developers are using jQuery, compared with 48% using ASP.NET AJAX and 58% using AJAX Toolkit. Does that really mean that there are more jQuery developers than WebForms/ASP.NET AJAX developers? To confuse matters, AJAX Control Toolkit is built ONTOP of ASP.NET AJAX. Yet these results show that there are more people using the toolkit than ASP.NET AJAX (which is actually impossible). I know from experience that there is a huge portion of web developers out there who never want to hear the word “Javascript”. Does that mean they’re not doing AJAX? No, they’re simply relying on the tools that were handed to them. Microsoft created the Microsoft ASP.NET AJAX stack and made doing things like partial rendering a breeze. It’s all part of ASP.NET 3.5. I don’t even call it “AJAX Extensions” anymore, it’s just ASP.NET 3.5, or Visual Studio 2008. It’s actually so easy to do Partial Updates at this point, that a developer can ‘do AJAX’ with out even knowing how to write a line of JavaScript. It’s very unlikely that those developers are or will be represented in this survey. How many web developers still use the term DHTML? That usually only shows up on resumes. But in actuality, most web developers today are doing DHTML, and aren’t even aware of it. I expect the same will be true of AJAX. It’s so commonplace that there’s no reason to differentiate it from web development in the first place.

So what spawned all of this? Well, I saw a post from Betrand Le Roy on Twitter about this survey. He immediately got a response asking “will the results of this survey be used to finally convince Microsoft to dump ASP.NET AJAX, and go with jQuery instead”. I can only hope not. jQuery is an awesome Javascript framework, but it absolutely abandons the web developer who doesn’t want to spend his days writing custom Javascript. Microsoft created the idea of a server-side webcontrol for this very reason. If I’m given the choice to drop an UpdatePanel on a form and have a label update on a button click via AJAX, or hand code it myself using a Javascript framework, I’m going to go with the UpdatePanel just about every time. Will I get more satisfaction out of building it from scratch? Certainly. But personal satisfaction doesn’t pay the bills. And I’d be much more satisfied spending the two weeks time I saved, on the beach fishing. The Infragistics ASP.NET controls try to find a comfortable balance between these two worlds. They abstract away the client-side javascript for developers who don’t want to or have the time to deal with it, and they provide a client-side object model for developers who want to dive in and play. We call it our CSOM (Client-Side Object Model) and it’s been around for years. I think this is the path Microsoft needs to continue to take, supporting both of these key scenarios.

But back to the topic at hand. Polls and surveys are just that. They represent a a sentiment of a select audience. Was the audience wide enough to capture multiple views (usually not). Was the survey done by an impartial third party (usually not). Did others have a chance to influence the results (unfortunately yes most of the time). And even when you get past all of that, it’s most important to look at what the questions were actually asking in the first place. Each time I see the results of a poll, I argue that the answer that was being deduced was not actually the question that was being asked.

My question to you – do you participate in these polls? How much weight/validity do you give the to results? And better yet, what do you think about “lobbying for votes” in readers choice type polls/awards? Is that something you would be happy to hear about, or would you prefer not to hear at all?

Perhaps I’m too analytical, but I generally tear apart survey results and the conclusions that are drawn from them.

Building A Silverlight 3 Dashboard With Composite UI

2009-04-14T22:06:06Z

If you’ve been following me on Twitter (igtony), you’ve probably heard me grumbling about Visual Studio crashing, services not working, or various other gremlins I’ve been fighting with for the past few days. Well, I’ve finally got something to show for all of my pain!

My goal when I started building this application was to build a POC Silverlight Application which dynamically loaded sub-applications. In essence, I wanted to build a Silverlight shell that could load N applications unknown at compile time. I started out by choosing from the new Navigation project template in Silverlight 3. This gives a MasterPage scenario that works as a good starting point for an application which may have multiple distinct Views. I tweaked the base appearance of the template around just to make it look a little more presentable. The White background used in the <Frame> element and the big 10px borders reminded me of Windows 3.1, and IE4. I used a Border element to create the rounded edges which wrapped around my Frame, and I set my Frame background to be transparent. With some of the UI tweaks out of the way, it was down to business.

The first task I needed to tackle was loading a XAML page (UserControl) dynamically. It turns out this is a pretty simple task as long as that user control is in the same XAP file. The Frame element has a Navigate method which takes a URI and will fill the Frame’s Content with the UserControl specified via the URI. Unfortunately, the solution I was looking for places my UserControl in a separate XAP file, which meant I couldn’t use the simple Frame.Navigate(URI) method. Instead I needed to dynamically load the UserControl in question. Luckily, this is a pretty straight forward task with the help of the WebClient.OpenReadAsync method, and AssemblyPart class. Here’s the code I used:

        private void NavButton_Click(object sender, RoutedEventArgs e)
        {
            Button navigationButton = sender as Button;
            //Create a WebClient instance to download our separate XAP file
            WebClient client=new WebClient();

            client.OpenReadCompleted+=new OpenReadCompletedEventHandler(client_OpenReadCompleted);
            //Download the XAP file
            client.OpenReadAsync(new Uri("CompositeApp.xap",UriKind.Relative));
        }

        void client_OpenReadCompleted(object sender, OpenReadCompletedEventArgs e)
        {

			//Create a StreamResourceInfo object out of our XAP stream            
			StreamResourceInfo sri = new StreamResourceInfo(e.Result, null);
			
			//Get a StreamResourceInfo for the Application's DLL
			//The one that houses our main XAML UserControl
            StreamResourceInfo mainAppSRI = Application.GetResourceStream(sri, new Uri("CompositeApp.dll", UriKind.Relative));
			
			//Load the Assembly using AssemblyPart.Load
            AssemblyPart loader = new AssemblyPart();
            Assembly assembly = loader.Load(mainAppSRI.Stream);
			
			//Now that the Assembly is loaded, create an instance of our UserControl
            this.Frame.Content = assembly.CreateInstance("CompositeApp.MainPage");
           
        }

There’s one drawback to using this method to dynamically load a UserControl – dependencies are not automatically loaded for you. If your UserControl in the separate XAP has a dependency on 4 assemblies you must manually load those 4 assemblies before loading your UserControl or CreateInstance will fail. The ~~hack~~ solution I used was to include the assembly references in the main shell application. This doesn’t scale well though, since ideally you want the additional dependencies to be loaded dynamically as necessary. There’s no way you’ll know today every assembly reference each sub app will need for the entire life of the shell. It’s actually impossible since you’ll likely need a ‘new’ assembly at some point down the road. I saw some code fragments while looking for a solution which read the manifest in the XAP to determine what assemblies need to be loaded out of the (external) XAP. If I were building this as a real world app, I would go that route. If you know of a better way to handle this, I encourage you to share in the comments! In a perfect world Frame.Navigate would allow you to specify a XAML file in a separate XAP and do all of this work for you. Are you listening Silverlight team? ;)

Ok, main hurdle down (dynamic loading of UserControl from separate XAP), it was time for the next challenge – creating content! I started out with a grid, because you can’t have a good application without a grid in there somewhere, right? I used the XamWebGrid, and used it in a couple of places. One on the main page which showed hierarchical data (Accounts and Transactions)

Next I created another ‘page’ or View which Visualized data in a Map. In this scenario the map shapes came from my “Shapefile” and the data came from a SQL Database via WCF and LinqToSQL. I think this probably mirrors the major use case out there, where the data is kept separate from the Shapefile.

On the final Screen, I went with ‘live’ updating data (Image 1). Since this was just a demo, I used a DispatcherTimer to change my underlying datasource every second. Since my underlying datasource was an ObservableCollection of INotifyPropertyChanged objects, my grid immediately showed any changes made to the underlying datasource. The Grid does 2-way databinding by default. Since my View still looked empty, I dropped a chart in there as well, and added a new datapoint to the chart’s DataPoints collection each second (representing the history of changes made to the grid). The end result was a chart and grid showing updates every second, with the Chart “always in motion”. It was a pretty impressive experience. My next step is to see what this would look like with a real data feed. I’m guessing with proper queuing in place, the experience should mirror my mock up almost exactly.

Another Code Camp, Another Good Time

2009-03-30T19:39:35Z

Over the weekend I hopped a train up to Waltham where I spoke at the New England Code Camp 11. As usual, there was a vibe in the air that made everything seem almost make believe – or maybe that was just the green tint on the projector.. Either way, if you haven’t been to a Code Camp yet, there’s no better time. Free content, free food, and great opportunities for networking. That’s not to mention the give-aways.

I spent a good amount of time in the Speakers lounge on Saturday and had the opportunity to meet some great people. I was introduced to “Pocket Coffee”, a chocolate John Doucette’s his wife picked up in Rome. It wasn’t any chocolate, it had an Espresso center. After trying one, I was immediately hooked and started feverishly searching Amazon.com to see where I could buy a case. Right before I had to leave to catch my train,I got into a long discussion about HDD’s and what the platters are made out of. Turned out I was talking to somewhat of an expert on the subject. Igor Moochnick told me about how he re-uses computer parts in his robotics side projects. All in all good fun, and it was great meeting you all.

The session itself was a hit (in my opinion). I did an introductory level JavaScript talk, packing years of experience into an hour long discussion. The session was more like a chalk talk than a standard “session”. Actually I didn’t have a single PowerPoint slide prepared, and spent 99% of the time inside of Visual Studio or Internet Explorer. If you were at the session and have any specific questions about the topics I covered feel free to use the comments section on this post.

I’m not sure who traveled the farthest to get to the Code Camp, but I know that I lost out to Steve Andrews and John Baird who drove up from the Philly area.

And speaking of Philly – The Philly Code Camp is coming up on April 18th. I’ll be there, just not speaking this time. I’m doing something a little different that I think you’re going to like. I’m setting up in the cafeteria all day, and I’ll be there to answer any questions you have about the Infragistics tools. Want to know what’s in the next release? Need help figuring out how to do something with one of the tools? Just stop on by. Feel free to bring your laptop and projects with you, we can do some hands on debugging.

NetAdvantage ASP.NET Controls – The Next Generation

2009-03-26T20:50:42Z

It’s a time of change here at Infragistics. We’re way past the half way point on our “Aikido” (Now officially just AJAX) framework, and with the 9.1 release many of the remaining classic Infragistics controls are being re-born as Web 2.0 loving replacements. I’ve got some mixed emotions, since I’ve been here long enough to have worked on these classics, but it’s an exciting time to see what the dev team has produced.

I was just checking out the WebDataMenu for example, which replaces the WebMenu (part of UltraWebNavigator for those of you who have been with us from the start). The WebDataMenu is databindable, and supports IEnumerable, XML, BindingList and ICollection. Basically, if you’ve got data, the WebDataMenu can handle it. DataBinding support is just the beginning though. It’s also built with Web 2.0 ideals embedded in its core. What do I mean? Well, a quick look at the HTML source and you’ll see the WebDataMenu is composed of <ul></ul> elements. Each Menu Item is a list item, meaning you can easily control the display of the WebDataMenu with CSS.

Add keyboard navigation (IE, FireFox AND Safari) and you’ve got a killer menu. Take it one step further and allow Menu Items to be templated and you’ve got the menu to rule them all! Seriously though, this menu is uber cool. The release is right around the corner, so you should be able to download and try it out very soon. Like before you do your income taxes soon..

Stay tuned for more about the 9.1 release. You can also follow along on Twitter as I push out information over the next couple of weeks.

Social Networking Fan? Information Junkie?

2009-03-26T18:36:35Z

If you haven’t found us yet, Infragistics is on both Facebook and Twitter. If you use either of these networks, you can follow us and get all of the latest information in a single place.

There are also a bunch of Infragistics employees up on twitter, for example you can follow me @igtony. I’ve just started talking about the 2009.1 release which I’ve tagged with #na91. Tagging allows you to easily search for a keyword. The # (hash) is used to differentiate ordinary words from tags. You can then use search.twitter.com to search for a particular tag.

There’s your tip to staying connected for today!

BTW, I’m headed up to Waltham MA tomorrow to speak at THE New England Code Camp. I’ll be up there tomorrow night (3/27/2009) looking for something to do. Shoot me a message on twitter (a tweet) if you’re in the area!

ViewState 101

2009-03-24T19:11:37Z

One of the most common complaints I hear about the Infragistics tools is “there’s so much ViewState, it’s bloated!”. One of the most common questions I hear is not surprisingly, “How do I reduce the ViewState?”. Before I jump into the answer (which is a simple “turn it off”), I want to discuss what ViewState is.

ViewState is an encoded string that is actually a list of serialized properties and values for a given control. Viewstate is how ASP.NET knows if a property has changed between postbacks. Suppose I had a textbox and I wanted to change the background color to red when the user clicks on a button. Easy task right? Well, what happens if the user then clicks on a different button. How does the application know to make the textbox red again? The button click code isn’t going to fire again, and the Page no longer exists on the server (it’s torn down and re-created with each request/postback). The fact that the background should now be read has to be stored somewhere – that somewhere is ViewState. Here’s some code:

<%@ Page Language="C#" AutoEventWireup="true"  CodeFile="Default.aspx.cs" Inherits="_Default" %>

<%@ Register Assembly="Infragistics35.WebUI.WebDataInput.v8.3, Version=8.3.20083.1002, Culture=neutral, PublicKeyToken=7dd5c3163f2cd0cb"
    Namespace="Infragistics.WebUI.WebDataInput" TagPrefix="igtxt" %>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">
    <title></title>
</head>
<body>
    <form id="form1" runat="server">
    <div>
        <igtxt:WebNumericEdit ID="WebNumericEdit1" runat="server">
        </igtxt:WebNumericEdit>
        <asp:Button runat="server" Text="Red" OnClick="TurnRed" />
        <asp:Button runat="server" Text="Submit" />
    </div>
    </form>
</body>
</html>

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Drawing;

public partial class _Default : System.Web.UI.Page 
{
    protected void Page_Load(object sender, EventArgs e)
    {

    }
    protected void TurnRed(object sender, EventArgs e)
    {
        this.WebNumericEdit1.BackColor = Color.Red;
    }
}

Clicking on the “Red” button turns the background of my textbox red. Then if I click on the “Submit” button and force a postback, the textbox background remains red. We often just take for granted that this works, but it’s ViewState that makes this work. Look at the HTML source in your browser and you’ll see something like:

<input type=”hidden” name=”__VIEWSTATE” value=”…..” /> The ViewState is stored as a string value in a hidden field, and it keeps track of all changes made at runtime to a particular object. When you set the backcolor to Red on the WebNumericEdit, that information gets encoded into the value seen in the __VIEWSTATE field. The next time the page is posted back, the control peeks into the __VIEWSTATE field and re-serializes itself based on what it finds. Let’s take a look at the example code above. When the page initially loads, this is what the __VIEWSTATE field looks like:

<INPUT id=__VIEWSTATE value=/wEPDwUKLTIyOTMwMjU4MmQYAQUeX19Db250
cm9sc1JlcXVpcmVQb3N0QmFja0tleV9fFgEFD1dlYk51bWVyaWNFZGl0MROii26o
a0DVPVO5sgHn/KcNr5fL type=hidden name=__VIEWSTATE>

That’s not very telling, so lets use a tool to decode this into clear text. You can download ViewState Decoder which is what I’m using below.

Notice that there’s not really anything of note in the ViewState except for what looks like some sort of identifier key. Now let's click on the Red Button and see what we get.

Notice there’s now an entry for a Color [Red]. If this value was not included in the __VIEWSTATE field, the next time the Page posted back, the background color would reset to White (the default). To understand more about how this works, lets take a look at the control lifecyle.

The first phase after a Page is requested is the Init, where the objects are created from the ASPX markup. After the Init the ViewState is “rehydrated” (deserialized) and the values are loaded into the appropriate controls/properties.

Note: This is a simplified model. There are additional steps like loading ControlState, and firing Events that I’ve left out for clarity.

Notice that the last step before Render is “SaveViewState”. When this method is called, every property that was ‘dirtied’ during the Page_Load will be persisted into the Value attribute of the __VIEWSTATE hidden field. Yes, I said – EVERY property. That’s the drawback of using ViewState, and the reason why it’s important to understand how it functions.

If you’re used to putting all of your initialization code in the Page_Load, inside of an if statement that checks that it’s not a PostBack, chances are you don’t need ViewState. Removing the if statement and having that code execute on each Page_Load will allow you to set EnableViewState=False on a particular control, or even the entire Page. The only case this doesn’t cover is the “I want to change the background-color of my TextBox to red on a Button Click”.

So you’ve read this far, I’m guessing you want an answer to the questions at the top?

Q: “Why is the ViewState field so big for Infragistics controls!?”

A: The size of the ViewState field is directly dependent on the number of properties you’re setting – as per the definition of ViewState. We’ve gone to great lengths to ensure that each property of our components participates in the ViewState lifecycle. That means if you set 200 properties in your Page_Load, 200 properties will end up in ViewState, just as you should expect.

Q: “Do I need ViewState?”

A: The short answer is no. In the scenarios above, I highlighted when and where you would want to use ViewState. Infragistics controls are meant to work with or without ViewState. If you don’t need to support the “I want to change the background-color of my TextBox to red on a Button Click” scenario, you can simply turn off ViewState. The only time I use ViewState is when I forget to turn it off.

Q: “How do I reduce the ViewState?”

A: Turn it off. There’s no in between for ViewState*, a control either tracks ViewState or it doesn’t. Even though controls don’t need ViewState to function, it’s turned on by default for every control (as part of the .NET Framework). Set EnableViewState=False on the control or Page level to turn off ViewState tracking.

*This brings me to one last topic, and one that takes the ViewState model to a whole new level – Grids. The WebGrid has a commonly overlooked feature built into it where it can persist the entire datasource into ViewState. Why do you need this you may ask? When a grid is editable it needs to track the old value and the new value – that way it can fire the appropriate Update events and give you a chance to revert back to the ‘old’ value. The old values can be persisted in ViewState in case your DataSource isn’t available the next time you post back. There may be cases where you simply can’t fetch your DataSource on each postback (for performance reasons), or you manually populated the grid with data, and there is no “DataSource” to bind to. In the WebGrid, you would turn off ViewState if you didn’t want the values to be persisted into the ViewState field. Again, the default for all ASP.NET controls is to have ViewState enabled, so in your typical application you likely have this turned on (and you most likely don’t even need it).

In the WebDataGrid we’ve made the ViewState serialization more granular and added a property to EnableDataViewState. The property is self explanatory I think, but just to be clear – set this to True if you want to embed your data into ViewState, set it to False to keep data out of ViewState. BTW, If you haven’t seen the WebDataGrid yet, go check it out now!

So the next time someone says “The ViewState is too big”, not only can you save the day by showing them how to turn it off, but you can also explain how ViewState works and why it's there in the first place.

March Craziness!

2009-03-19T22:02:30Z

If you haven’t seen, there’s a ton of new downloads available from Microsoft. IE8 has finally been released!

There were also some nice announcements made at Mix09. Most anticipated was the Silverlight 3 features. Some of the highlights are below.

Silverlight 3

Video & Audio enhancements (H.264 support!)
Perspective 3D graphics
Pixel Shader effects
Dynamic Styles with Inheritance (cascading Styles)
Element to Element binding
Data Validation
RIA Services support
Out of Browser Capabilities

That’s an impressive list. If I were to pick some of my favorites, it would have to be improved Data Binding support and Out of Browser Capabilities. From day one when I heard the plans for Silverlight, all I could think of was how the browser was just this lame shell used to launch the application. I guess the folks at Microsoft were thinking the same thing. Plus, you don’t have to worry about back button support anymore.. ;)

I installed SL3 bits today, as well as IE8. I already experienced a crash in IE8, which is strange, and I’m not yet ready to blame IE but I’ll certainly have to do some more diagnostics. Haven’t had a chance to build with SL3 yet. My only complaint so far is that the install is SLOW. Actually the uninstall for SL2 Tools seemed to be really slow, the Install for SL3 tools was just slow. I’ll keep you posted!

Best Practices on Best Practices?

2009-03-11T20:19:02Z

So the other day I was helping out a coworker on a project and was taken aback by the complexity of the project. I was expecting a hacky WinForms app with a single form and one monolithic method. Instead, I saw an organized solution with 6 projects, including a test project. It took me a good 30 minutes to follow through the logic from one class to the next, across projects and assemblies. This of course made me feel dumb, so my first reaction was – this project is too complex!

So while discussing the project with some others to get ideas of what could be wrong, I happened to say - “there’s a time and a place for best practices”. There was a moment of silence and then I got looks like I had just walked into a courtroom wearing a blue velour suit. Because of the various reactions, I thought this would be a good topic to discuss with you.

I’ve always been a believer in the “do what it takes to get the job done” camp. I like to follow best practices until they get in the way. There, I said it.. I’m not going to hide it anymore! I believe that a “best practice”, just like most patterns has a certain solution set that it’s best fit for. I’m not saying throw caution to the wind and forego every bit of programming common sense, but would I use MVVM the next time I want to write a quick utility application? Probably not. I follow a rule of thumb – if the pattern I’m using is more complex than the solution the software is supposed to be providing, I’m not going to use it. It all boils down to ROI – what benefits do I get by following this pattern and how much is it going to cost me to do it?

Here’s a perfect example. MVC is getting a lot of buzz right now, and seems like a good solution for a certain set of applications. Does that make it better than ASP.NET’s classic MVP pattern? I’ve grown fond of the idea of dropping a control on a form, writing a couple lines of code and being done. Am I about to dump all of that because MVC is the new hot pattern? I think you know the answer to that already. That’s not to say MVC isn’t useful – as I said earlier there is a problem/solution set that MVC is perfect for. It just turns out, that’s not the problem set I’m normally involved in..

So what do you think about all of this? Are you a pattern / best practices follower? Have you found certain ones worthwhile, or vowed never to use a one (or many) ever again? Leave your thoughts in the comments.