Web Control Development

JS Intellisense in Orcas

Joel Rumerman — Sat, 03 Mar 2007 17:43:00 GMT

It’s finally here!!

JavaScript intellisense is available in the March 2007 CTP of Orcas (the next Visual Studio). It works well with plain old JavaScript, but it really shines with ASP.NET AJAX.

Jeff King does a good job of documenting the new capabilities in this blog entry.

For us ASP.NET Server Control developers that utilize client capabilities, this is a huge boon for us. When was the last time JS intellisense was updated?? Anybody? I have no idea… I don’t think it’s changed since the first release of Visual Studio. Having to program ASP.NET AJAX client runtimes with intellisense … AWESOME!!!

Also, I mentioned an excellent article in my webcast that describes the prototype/closure model. I finally found it… here it is.

IMHO, it’s the single best article that describes closures available.

ASP.NET AJAX Client Component Development WebCast

Joel Rumerman — Thu, 01 Mar 2007 12:08:00 GMT

Hello Everyone,

Thanks so much for attending today’s webcast! We had 150+ attend and this is just a testament to how important and interesting a subject MS ASP.NET AJAX is.

As promised, here is the source code from today’s webcast. This is free source code, no limits on modifications, re-use, redeployment to clients, etc. I don’t even have my name in it yet.

I will add however, that the component that is supplied in this source code only works in certain situations. Try sticking a button you want to disable within an UpdatePanel and see what happens. It’ll work the first time, but in subsequent partial postbacks. There’s another, longer version of the source code that I’m working on that is more fully-baked that can be reused successfully across web applications and in different scenarios.

Again, thanks for joining me today on the webcast. I hope you enjoyed it and learned something interesting! Stay tuned for more webcasts regarding ASP.NET AJAX custom development. I think I’m going to put a couple of more in the pipeline.

Download Source

February SD .NET Developers Group Talk on ASP.NET AJAX Component Creation

Joel Rumerman — Wed, 07 Feb 2007 16:01:00 GMT

Thanks to everyone that attended the meeting and heard my talk about ASP.NET AJAX Component Development. We had a great time hosting and I hope it sparked some interest in ASP.NET AJAX Component development and that you were able to learn something new.

Here are the slides and code from my presentation. I’m not attaching the postback disabler control at the moment (the last thing I demoed at the meeting) as it’s not ready to go yet and I think I’ll blog more in-depth about it in the next few weeks.

Happy coding, and thanks for attending!!

File Attachment: ASP.NET AJAX Component Development.ppt (745 KB)

File Attachment: DemoAJAXWebsite.zip (22 KB)

Atlas: Page Lifecycle for Partial Postbacks

Joel Rumerman — Sun, 23 Apr 2006 18:58:00 GMT

A piece of information that I’ve tended to gloss over until now was that during a partial postback by means of an Atlas UpdatePanel, the server life cycle goes through a normal postback life cycle. I never gave this much thought until I was considering what this meant for performance. Were all of my controls re-rendering even if they weren’t contained within an UpdatePanel that was set to update? How did the server side Atlas framework know to only send the HTML for the controls that were contained in an updating UpdatePanel down stream? Was there a way to make my code perform better knowing that I was working within the Atlas framework?

The simple answers: Yes. The framework is smart. I’m not too sure.

The more complete answers ….

All controls are participating in the postback in normal life cycle fashion. Their viewstate is loaded; their controls created; their data, bound. The major difference occurred when it came to any of the render methods (BeginRender, Render, EndRender, AddAttributesToRender, etc.) that normally had an HtmlWriter parameter. Here, in one of the previously stated methods (e.g. Render) an updating UpdatePanel used a normal HtmlWriter parameter as expected. However, in the same method within a control that wasn’t within an updating UpdatePanel, the parameter was of type Microsoft.Web.UI.DummyHtmlTextWriter. Whoa … what this means is that there are two HtmlWriters. Whether you are going to be re-rendered down to the browser or not determines which HtmlWriter is used. (BTW, thank Microsoft for creating the DummyHtmlWriter type. I’m pretty sure that they could have used a NullTextWriter when they didn’t want a control’s output to be sent to the browser, but if nothing else, the DummyHtmlWriter makes it really clear that this control isn’t actually going to be sent to the browser.)

The next logical question I had was why Microsoft didn’t program it so that if a control wasn’t going to be re-rendered and sent down to the browser it never entered the Render phase and therefore eliminating the need for the new DummyHtmlWriter type? The answer actually came from Microsoft because I was stuck on this one for a while. The reason for this was because the EventValidation hashcode is created in the Render method and when a page has EventValidation enabled (as all pages do normally and it’s the default) the base Render method must execute at the appropriate time in order for this hashcode to be created. (As a side bar, to understand the Event Validation, see K Scott Allen's Blog Entry on Event Validation or Shawn Burke's Blog Entry on the Cascading Dropdown Control, but it pretty much prevents unauthorized postback values.) Therefore, in order for a page’s EventValidation hashcode to be correct, all of its child controls must execute their render methods to create their hashcodes which can be passed up the chain and hence the reason that all controls must be re-rendered.

Up until now, I’ve answered my first two questions, but is there a way, knowing I’m working within the Atlas Framework, to program slightly differently to make my code run faster? Truth-be-told, I don’t see too much. There’s a basic knowledge of knowing that I’m in a postback and therefore loading or not loading data as appropriate, but other than that I’m not sure.

A question remains … I have a drop down with the values 1, 2, 3. They are rendered initially, but not re-rendered on a postback. An UpatePanel causes a partial postback (does not contain the dropdown). Will I get an EventValidation exception if I perform a normal full postback? So normally if I perform a postback I would have to re-render the dropdown either from ViewState or from my initial data in order for the dropdown to display. But, if I perform a partial postback my dropdown values will still exist on the page because I’m not replacing the Html associated to that area of the page. But the page’s EventValidation hashcode won’t contain the dropdown’s values because they were never re-rendered. What happens when I perform a normal postback?? I’ve been sitting in front of my computer on an awesome Sunday for way too long to test this right now, but I’ll post a follow up soon.