Jeff's Blog

Okay, so why not just stick inside the toolkit and use the DynamicControlID / DynamicServiceMethod. Why futz around with all this extra work when there's a perfectly fine built in functionality that will do just about everything I need it to. Well, first, it's not quite what I need, this is one of those cases where, if you just want a ModalPopup, not a ModalDialog things will be very good for you. Unfortunately there are some problems. Let's look at this over simple example

Any guesses as to what happens with this inline JavaScript? Nada, just like any innerHTML assignment, without additional client-side processing. Sure we're handling that with the WebMethodUIUpdateLink that we've created, but in this case we'd have to inject some code on the clienside _endrequestHandler to do the post processing, and have to make clientside decions about when and where to do this processing. All of which is totally doable, but we're straying off the beaten path, so it might make sense to take a little more control.

The second issue I have is that using the dynamic hooks further abstracts you from what you are trying to build. Don't get me wrong, I am amazed at how well designed and implemented the Ajax Extensions, and the Ajaxtoolkit is, but it doesn't feel right to use such a powerful tool without first cutting ones teeth on the painful cycles of targeted browser development.

It might help to mention, that I have the same general view of the Typed DataSet. The Typed DataSet is the single most useful and dangerous package of functionality I've ever seen. When used in an appropriate fashion the dataset not only saves development time, but adds stability and conformity that is quite unexpected. But it's far too easy to push yourself off of a cliff with a DataSet, especially if you don't have a thorough understanding of both its purpose and its implementation.

Conclusion:

One more time from the top; it's just not going to be easy, and as long as you're comfortable with that you'll be constantly astounded as to what is possible in the world of dynamic Client UI. Silverlight you say? Sure it will make some things much easier, but trust me the hard parts are only going to get harder, that's how it always works.

The thing that I've gotten out of this post series is a reassurance that I can work with the Ajax Extensions, and the Toolkit to get the end desired effect. For some time I've wavered on this point both because of the sheer overhead on the client that's involved with using it, and because I'm somewhat of a control freak who just can't seem to trust anyone else's interpretation of the Wild Wild West that is the AjaxWeb.

If I had to say the what/when/where of whether I would use and UpdatePanel vs. a WebMethod at this point, I would have to wiggle out of a direct answer and only say, only the websites with the strictest performance requirements should really consider using something other than an UpdatePanel, at least in the context of a Modal Dialog. I'm saying that knowing that I am not entirely comfortable with the way UpdatePanels work. Part of that is the cost of rendering the full page when I really only want to update a small portion, and part of it is coping with the unintended consequences of that full page submit.

Picture a typical online shopping experience. You work your way through the stores product lists perhaps with the help of some modal dialogs to provide product details, and you finally click the "Checkout" button. Now you are faced with the login screen, if you're lucky you're already a registered user, and you simple have one out of flow screen to deal with, enter your username and password and in short order you're checking out. On the other hand if this is your first time through, get ready to feel uncomfortable, you're going to have to navigate at through at least one registration screen, and probably several more. Why uncomfortable? Well, even thought I know better I always wonder, will something go wrong, will this site lose my 'basket' and will I have to endure the work of recreating it?

Now picture that same scenario with a modal popup dialog of sorts. Here's a great opportunity to help keep a user in their flow while enabling them to provide information that system requires to complete their requested transaction. Using an UpdatePanel here is a perfect marriage. Now change that scenario again. Let's say the user is filling out a standard WebForm, but you want to have to have some context sensitive help using the a modal popup, you might be able to use the DynamicServiceMethod, as long as you're content is pretty vanilla, but if you have something complex to render, a good choice is the modal popup using an UpdatePanel. Only what do you do with a user's data when they navigate through the help dialogs? Do you store it, what if they don't end up hitting the submit button on the page, what then do you dispose of it, and if you do when, and how do you make that determination.

I'm repeating myself here, but the point is that, for the most part, if you just do what the pre-packaged pieces let you, you'll be happy. If you're developing for real requirements, you just might not be.