A Blog for Graymad

• 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.

• Cross-page posting - In Whidbey, you will be able to post Web Forms to pages other than the page on which the input is entered. Postback target is chosen based on the PostTargetUrl (interim name) attribute of a control that causes a postback. On the target page, you will be able to access all of the controls, viewstate, etc. of the page that caused the web form post. Whidbey hangs a PreviousPage object off the current page to provide access to the controls, etc. of the posting page. Because it's based on postback controls, you can have a page that both posts back to itself, and also posts to another page, depending on which control is clicked.
• Validation Groups - The new feature validation groups allows you to logically group a set of validation controls, and only validate the fields that are in the group to which belongs the postback control that the user clicks. Uses the ValidationGroup attribute to implement in declarative tags. The key here is that you can have two sets of form fields that aren't typically used together, and implement validation on both sets of fields, without the non-used fields causing the page to fail validation.
• Wizard UI - New <asp:wizard> control that enables step-by-step wizard UI, for example for gathering multiple pages of input for a single purpose before saving or processing the input. The Wizard control defaults to a Next/Previous UI, but is also templated, so you can customize the UI to your needs. In combination with the Personalization and Membership providers, you can use the Wizard control to very easily create a UI for registering new users for a web site, etc.
• Image Generation - New feature for generating images in Whidbey. Includes an HttpHandler (.asix) providing a custom handler and base class for image generation, including support for downlevel rendering. Also includes a new DynamicImage control that uses callbacks with the image generation handler to pull down dynamically generated files.
• .asix files use the @ Image directive and inherit from System.Web.UI.Image.ImageGenerator. Does not require registering your own custom HttpHandler for image generation. Just write the code.
• The <asp:dynamicimage> control supports databinding. You can bind its imagebytes property to a data column that contains binary image data.
• URL Rewriting/Mapping - new built-in module for rewriting paths. Allows the use of "vanity" urls, instead of ugly querystrings, and also makes it easy to move content without breaking existing links. Perf tip: - This feature makes it possible to use kernel-level caching in IIS 6 for pages that would otherwise need querystring or form fields to perform the mapping.
• Site Counters - Provides a service and API for efficient logging and tracking of site visitors. Can also be accessed through attributes (CountClicks, CounterGroup, etc.) on declarative tags, as well as through web.config.
• Client Script Goodies - Server buttons now have an OnClientClick attribute for client-side handling. Focus mechanisms are now built into the page and controls. A page can also have a default button and a default focused control. All these features emit the appropriate client-side script. There will also be automatic scroll position maintenance in the beta release of Whidbey (not in the PDC bits).
• Whidbey adds support for custom build providers. ASP.NET allows you to register to receive notification of files needing dynamic compilation. Whidbey uses this feature to support dynamic compilation of .wsdl, .xsd, and .resx files in the /code directory of an ASP.NET application.
• No-compile Pages - You can configure at the page and folder level whether pages can be compiled after they've been deployed. If compilation is disabled, any change to the page after the page or directory has been locked down will throw an exception.
• File System Provider - allows Web content (both compiled and non-compiled) to be stored in non-filesystem locations such as databases or CMS, and even use Sql Cache invalidation to output cache stored content, while always getting the updated content if it changes. Pretends to be the filesystem and provides an interface into whatever storage location the content is actually stored in. Cannot store assemblies, but can store just about any other content.
• Securing non-ASP.NET Content - Requires IIS 6.0, using its ExecuteUrl feature. This allows forms authentication to work with static files like .jpg, .gif, etc.
• RSS Reader - Combine an XmlDataSource control and a DataList control to read and render any RSS feed.

Improved Data Source caching:

• Exposed via properties on datasource controls (EnableCaching="True", CacheDuration="5", etc.). Greatly simplifies the use of caching with data, as simple or simpler than output caching.
• Added SQL Cache Invalidation - automatically purges cached output or data when the underlying data is changed. Again, this is exposed via properties on the datasource controls (can be configured in the @ Page directive of ASP.NET pages as well).
• Caching also allows you to pull more data, and use the filtering functionality of the datasource controls to view subsets of data, without incurring the expense of pulling the data from the database on each request.
• New configuration section in web.config for Connection Strings. MMC Snap-in for configuring ASP.NET allows GUI access to this config section, and you can also access them via the configuration API. In declarative code, it uses a
  
     <%$ connectionname:tablename %>
  
  syntax for accessing a given connection.
• New DetailsView control, provides a more intuitive way of providing the details portion of a master-detail relationship, with the GridView control handling the master portion of the relationship. DetailsView provides an easy UI for inserting/updating data.
• Added new syntax for databinding in templates:
  
  <%# Eval("field") %> 'for one-way binding
  
  <%# Bind("field") %> 'for two-way binding
  
  
• Both GridView and DetailsView support two-way databinding (this feature is not in the PDC build of Whidbey).
• Templated databinding supports drag and drop of controls to be databound within, for example, a DetailsView control that is in template editing mode.
• New hierarchical DataSource controls - provide access to XML files and ASP.NET site maps, for example, and integrate with new controls designed to render hierarchical data, such as the TreeView control.
• All templated controls now also support databinding to XML, using XPath databinding expressions.

Finally got a chance to meet Kent Sharkey, who's responsible for the MSDN ASP.NET Developer Center. Kent works very, very hard to make sure that MSDN supplies the best and freshest content for ASP.NET developers, so if you see him, say “thanks”...he definitely deserves it. Kent got a whole raft of Whidbey-related ASP.NET articles launched on MSDN even in the midst of the travel nightmare that getting from Seattle to LAX became this week thanks to the wildfires here.

Clearly, the coffee vendors haven't gotten the .NET message yet, so this intrepid soul took matters into his own hands:

If you're interested in hearing the PDC perspective from noted industry figures like Brent Rector, Jeff Prosise, Dan Appleman, and Mike Amundsen, you can check out the interviews being done by Sys-Con Radio from the show floor. You can also find my interview here.

Improved Project System

• No need for FrontPage
• Supports file system webs, allowing ASP.NET development even when IIS is not installed locally (Whidbey ships with its own lightweight Web server)
• Build and debug without being an Admin
• Directory-based project system (reduces contention for project files)
• Makes it easy to do single-file editing, with complete IntelliSense support.
• When you create a project, very few files or folders are created automatically. When the IDE needs to add something (such as a web.config to enable debugging), the user is provided with a notification before the file is added.
• Debugger visualizers allow you to hover over an object at debug time and get an expanded view of the state of that object.

Remote Site Publishing

• Support for UNC, FTP, SharePoint, IIS (IntelliSense works for all of these scenarios)
• Publish all files or individual files, and keep local and remote sites in sync easily
• Logging is built into the Remote Publishing Wizard

Source Editor Improvements

• Intellisense Everywhere - in inline code and codebehind, in script blocks, in CSS styles, in web.config (yay!), and in XML files.
• Added tools to navigate your code - view at a glance the hierarchy of tag relationships.
• Outlining is available to allow you to expand or collapse on a tag-by-tag basis
• Code formatting (which can be turned off completely...really completely) can be customized based on tag categories (server vs. client) and even on a per-tag basis, allowing you to format upper/lower case, self-closing or paired tags, line breaks, etc. Formatting options for the client also determine what the server controls render to the client, making it very easy to write XHTML-compliant code.
• Cleaner code-behind. Based on partial classes, removes the requirement for separate control declarations in code-behind, and other "generated goop".
• If you select text in Source view, then switch to Design view (or vice versa) your selection is preserved, so selecting an element in Design view makes it easy to locate the tags for that control.
• Drag and drop is supported in Source view.
• Formatting us supported at the page level, as well as at the selection level, and does not automatically introduce whitespace when formatting.
• The formatter also supports automatic word-wrapping of tags.
• Tag formatting can be customized based on whether the tag contains content or is a self-contained tag, in addition to the parameters discussed above.
• The IDE supports exporting and importing of your desired formatting settings, so it's easy to share formatting across a development team to enforce a standardized format.
• Everything built in the design surface is validated to XHTML 1.1, and can optionally be validated against various browsers, and even accessibility standards.
• IntelliSense is now even supported in the @ Page directive, as well as in all inline code, including in <% %>blocks.

Whidbey Design Surface

• Never, ever, EVER, modify your code (without your asking)
• 100% XHTML 1.1 compliant and uses styles for formatting.
• Master pages provide shared layout, and provides visual representation of both the master page, and the customized content
• User Controls are rendered on the design surface
• Added smart tags to expose common control tasks (databinding, autoformatting, etc.)
• Improved table editor, with both pre-existing table templates, and/or editable table attributes.
• Added visual feedback for resizing templates, including display of the changes in pixel measurements (or percent, depending on how you defined the table) as you resize.

Faster Web Development

• No builds, save and refresh and see your changes.
• Faster project open time.
• Build Page feature - Allows you to locate compilation errors and validation problems on a page-by-page basis.
• New Code directory that provides dynamic compilation and linking for class files, including Intellisense support.
• Easier for teams to develop together since a compiler error on a single page doesn't prevent others from working on different pages.
• Pre-compiler allows you to compile your entire application (including HTML and other tags) into a single assembly, which runs just like an app deployed with source code.

Seamless Upgrades

• Allows you to upgrade a v1.1 application to Whidbey seamlessly.
• You can choose in-place upgrade, or make a copy to modify to the new version.

IMPORTANT! Not all of these features are in the PDC bits...about 2/3rds are there, and the rest will be in the beta coming in the spring.

Eric Rudder's keynote is focused on coding for current technology and Whidbey. "What we hear from you" was an early theme:

• I need more code samples (in my language)
• How do I support different languages?
• etc.