Sign in
|
Join
Search
A Blog for Graymad
Musings about ASP.NET and more...by G. Andrew Duthie
RSS
Atom
Comments RSS
Home
About
Tags
.NET / ASP.NET Community
Announcements
ASP.NET / Coding
Current Events
Longhorn
Musings
PDC/Conferences
Security
Whidbey
Writing
Navigation
Home
Blogs
Archives
August 2004 (1)
July 2004 (12)
June 2004 (4)
May 2004 (5)
April 2004 (3)
March 2004 (8)
February 2004 (3)
January 2004 (13)
December 2003 (8)
November 2003 (30)
October 2003 (33)
September 2003 (8)
August 2003 (8)
July 2003 (7)
June 2003 (16)
May 2003 (17)
April 2003 (30)
March 2003 (11)
February 2003 (8)
Articles (MSDN, etc.)
DNS and WHOIS in ASP.NET
Not Your Father's ASP
Design-time Support for ASP.NET Server Controls
Books
Good folks to know
INETA (International .NET Association)
CodeWise Community
Other Blogs
Steve Smith's Blog
Scott Guthrie's Blog
Rob Howard's Blog
Robert Scoble
Scott on Writing
Live @ Sax.net
Julie Lerman's Blog
Scott Cate's KBBlog
Critical Section
Sites I Like
The ASPAlliance
www.asp.net - Where it all starts!
ASP.NET Forums
MSDN ASP.NET Developer Center
WSV 401 - Building Server Controls for ASP.NET Whidbey (Part 1)
Posted
Wednesday, October 29, 2003 7:49 PM
by
G Andrew Duthie
Nikhil Kothari discusses Control Building
Nikhil's demo slides and code are available at http://www.asp.net/whidbey/ as well as on his blog at http://www.nikhilk.net/, where he will post samples of his demo controls that will work with the
PDC
build of Whidbey as well as with the forthcoming beta release.
Nikhil started with a demo of the finished control that he's using to demonstrate his points, an HTML Editor control.
A new base class has been added to the framework called CompositeControl, which encapsulates much of the work for composite controls. This class implements INamingContainer, so you don't have to do that manually anymore. Controls are still added by overriding CreateChildControls.
New notion is that you override the Render method in composite controls to render layout for your controls.
Cleaner APIs have been added for sending client-side script to the browser, including referencing a .js file, as well as for common tasks like setting focus on the client side.
Web resources are a new feature that allow you to package scripts, images, style sheets, and more as assembly resources. Using the Page.GetWebResourceUrl method, you can access these resources programmatically (uses an HttpHandler under the covers). This means that control developers no longer need to ship images, etc. and figure out how to get them installed on the control user's machine. Much less brittle model. Also automatically works at design-time, so images, etc. show up on the design surface in addition to working at runtime.
Another new feature is script callbacks. Script callbacks allow you to make requests back to the server to retrieve information from the page, without navigating away from the existing page. So you can now update a page seamlessly without postbacks. Script callbacks cause the target page to be instantiated, but it does not go through the entire page lifecycle, only the amount necessary to create and rehydrate its controls, and fire the scriptcallback event. It also solves two problems of postbacks: losing scroll position, and the back button. Because the browser never navigates away from the current page, the user can't use the back button to re-play the interaction.
Improvements in State Management - Addressing the limitations/issues with ViewState. New feature is Control State...used to store
essential
information about that control. Control State is separate from ViewState, allowing ViewState to be disabled without breaking controls. Control State is opt-in, so controls must register their interest in maintaining Control State with the page (call Page.RegisterRequiresControlState). Important to keep the information stored as small as possible. The idea is to avoid having Control State become as bloated as ViewState sometimes becomes (such as when using a DataGrid with many rows and columns).
Adaptive Rendering - Whidbey will provide support for helping control developers to target their controls to multiple browsers and/or devices, using different HtmlTextWriter types and/or Adapters. Nikhil hinted that one possible use of this feature would be to generate XAML from ASP.NET (see, I
told you
XAML was ASP.NET for Windows guys!). You can write your own custom adapters for devices/browsers you wish to target, if existing adapters don't meet your needs.
Comments
No Comments
Leave a Comment
Title
(required)
Name
(required)
Your URL
(optional
)
Comments
(required)
Remember Me?