In
the last installment I talked about
the core changes in
the ASP.NET runtime that I’ve been taking advantage of. In this column, I’ll cover
the changes to
the Web Forms engine and some of
the cool improvements in Visual Studio that make Web and general development easier. WebForms
The WebForms engine is
the area that has received most significant changes in ASP.NET 4.0. Probably
the most widely anticipated features are related to managing page client ids and of ViewState on WebForm pages. Take Control of Your ClientIDs Unique ClientID generation in ASP.NET has been one of
the most complained about “features” in ASP.NET. Although there’s a very good technical reason for these unique generated ids - they guarantee unique ids for each and every server control on a page - these unique and generated ids often get in
the way of client-side JavaScript development and CSS styling as it’s often inconvenient and fragile to work with
the long, generated ClientIDs. In ASP.NET 4.0 you can now specify an explicit client id mode on each control or each naming container parent control to control how client ids are generated. By default, ASP.NET generates mangled client ids for any control contained in a naming container (like a Master Page, or a User Control for example).
The key to ClientID management in ASP.NET 4.0 are
the new ClientIDMode and ClientIDRowSuffix properties. ClientIDMode supports four different ClientID generation settings shown below. For
the following examples, imagine that you have a Textbox control named txtName inside of a master page control container on a WebForms page. <%@Page Language="C#" MasterPageFile="~/Site.Master" CodeBehind="WebForm2.aspx.cs" Inherits="WebApplication1.WebForm2" %> <asp:Content ID="content" ContentPlaceHolderID="content" runat="server" ClientIDMode="Static" > <asp:TextBox runat="server" ID="txtName" /> </asp:Content>
The four available ClientIDMode values are: AutoID This is
the existing behavior in ASP.NET 1.x-3.x where full naming container munging takes place. <input name="ctl00$content$txtName" type="text" id="ctl00_content_txtName" /> This should be familiar to any ASP.NET developer and results in fairly unpredictable client ids that can easily change if
the containership hierarchy changes. For example, removing
the master page changes
the name in this case, so if you were to move a block of script code that works against
the control to a non-Master page,
the script code immediately breaks. Static This option is
the most deterministic setting that forces
the control’s ClientID to use its ID value directly. No naming container naming at all is applied and you end up with clean client ids: <input name="ctl00$content$txtName" type="text" id="txtName" /> Note that
the name property which is used for postback variables to
the server still is munged, but
the ClientID property is displayed simply as
the ID value that you have assigned to
the control. This option is what most of us want to use, but you have to be clear on that because it can potentially cause conflicts with other controls on
the page. If there are several instances of
the same naming container (several instances of
the same user control for example) there can easily be a client id naming conflict. Note that if you assign Static to a data-bound control, like a list child control in templates, you do not get unique ids either, so for list controls where you rely on unique id for child controls, you’ll probably want to use Predictable rather than Static. I’ll write more on this a little later when I discuss ClientIDRowSuffix. Predictable
The previous two values are pretty self-explanatory. Predictable however, requires some explanation. To me at least it’s not in
the least bit predictable. MSDN defines this value as follows: This algorithm is used for controls that are in data-bound controls.
The ClientID value is generated by concatenating
the ClientID value of
the parent naming container with
the ID value of
the control. If
the control is a data-bound control that generates multiple rows,
the value of
the data field specified in
the ClientIDRowSuffix property is added at
the end. For
the GridView control, multiple data fields can be specified. If
the ClientIDRowSuffix property is blank, a sequential number is added at
the end instead of a data-field value. Each segment is separated by an underscore character (_).
The key that makes this value a bit confusing is that it relies on
the parent NamingContainer’s ClientID to build its own ClientID value. This effectively means that
the value is not predictable at all but rather very tightly coupled to
the parent naming container’s ClientIDMode setting. For my simple textbox example, if
the ClientIDMode property of
the parent naming container (Page in this case) is set to “Predictable” you’ll get this: <input name="ctl00$content$txtName" type="text" id="content_txtName" /> which gives an id that based on walking up to
the currently active naming container (the MasterPage content container) and starting
the id formatting from there downward. Think of this as a semi unique name that’s guaranteed unique only for
the naming container. If, on
the other hand,
the Page is set to “AutoID” you get
the following with Predictable on txtName: <input name="ctl00$content$txtName" type="text" id="ctl00_content_txtName" />
The latter is effectively
the same as if you specified AutoID because it inherits
the AutoID naming from
the Page and Content Master Page control of
the page. But again - predictable behavior always depends on
the parent naming container and how it generates its id, so
the id may not always be exactly
the same as
the AutoID generated value because somewhere in
the NamingContainer chain
the ClientIDMode setting may be set to a different value. For example, if you had another naming container in
the middle that was set to Static you’d end up effectively with an id that starts with
the NamingContainers id rather than
the whole ctl000_content munging.
The most common use for Predictable is likely to be for data-bound controls, which results in each data bound item getting a unique ClientID. Unfortunately, even here
the behavior can be very unpredictable depending on which data-bound control you use - I found significant differences in how template controls in a GridView behave from those that are used in a ListView control. For example, GridView creates clean child ClientIDs, while ListView still has a naming container in
the ClientID, presumably because of
the template container on which you can’t set ClientIDMode. Predictable is useful, but only if all naming containers down
the chain use this setting. Otherwise you’re right back to
the munged ids that are pretty unpredictable. Another property, ClientIDRowSuffix, can be used in combination with ClientIDMode of Predictable to force a suffix onto list client controls. For example: <asp:GridView runat="server" ID="gvItems" AutoGenerateColumns="false" ClientIDMode="Static" ClientIDRowSuffix="Id"> <Columns> <asp:TemplateField> <ItemTemplate> <asp:Label runat="server" id="txtName" Text='<%# Eval("Name") %>' ClientIDMode="Predictable"/> </ItemTemplate> </asp:TemplateField> <asp:TemplateField> <ItemTemplate> <asp:Label runat="server" id="txtId" Text='<%# Eval("Id") %>' ClientIDMode="Predictable" /> </ItemTemplate> </asp:TemplateField> </Columns> </asp:GridView> generates client Ids inside of a column in
the master page described earlier: <td> <span id="txtName_0">Rick</span> </td> where
the value after
the underscore is
the ClientIDRowSuffix field - in this case “Id” of
the item data bound to
the control. Note that all of
the child controls require ClientIDMode=”Predictable” in order for
the ClientIDRowSuffix to be applied, and
the parent GridView controls need to be set to Static either explicitly or via Naming Container inheritance to give these simple names. It’s a bummer that ClientIDRowSuffix doesn’t work with Static to produce this automatically. Another real problem is that other controls process
the ClientIDMode differently. For example, a ListView control processes
the Predictable ClientIDMode differently and produces
the following with
the Static ListView and Predictable child controls: <span id="ctrl0_txtName_0">Rick</span> I couldn’t even figure out a way using ClientIDMode to get a simple ID that also uses a suffix short of falling back to manually generated ids using <%= %> expressions instead. Given
the inconsistencies inside of list controls using <%= %>, ids for
the ListView might not be a bad idea anyway. Inherit
The final setting is Inherit, which is
the default for all controls except Page. This means that controls by default inherit
the parent naming container’s ClientIDMode setting. For more detailed information on ClientID behavior and different scenarios you can check out a blog post of mine on this subject: http://www.west-wind.com/weblog/posts/54760.aspx. ClientID Enhancements Summary
The ClientIDMode property is a welcome addition to ASP.NET 4.0. To me this is probably
the most useful WebForms feature as it allows me to generate clean IDs simply by setting ClientIDMode="Static" on either
the page or inside of Web.config (in
the Pages section) which applies
the setting down to
the entire page which is my 95% scenario. For
the few cases when it matters - for list controls and inside of multi-use user controls or custom server controls) - I can use Predictable or even AutoID to force controls to unique names. For application-level page development, this is easy to accomplish and provides maximum usability for working with client script code against page controls. ViewStateMode Another area of large criticism for WebForms is ViewState. ViewState is used internally by ASP.NET to persist page-level changes to non-postback properties on controls as pages post back to
the server. It’s a useful mechanism that works great for
the overall mechanics of WebForms, but it can also cause all sorts of overhead for page operation as ViewState can very quickly get out of control and consume huge amounts of bandwidth in your page content. ViewState can also wreak havoc with client-side scripting applications that modify control properties that are tracked by ViewState, which can produce very unpredictable results on a Postback after client-side updates. Over
the years in my own development, I’ve often turned off ViewState on pages to reduce overhead. Yes, you lose some functionality, but you can easily implement most of
the common functionality in non-ViewState workarounds. Relying less on heavy ViewState controls and sticking with simpler controls or raw HTML constructs avoids getting around ViewState problems. In ASP.NET 3.x and prior, it wasn’t easy to control ViewState - you could turn it on or off and if you turned it off at
the page or web.config level, you couldn’t turn it back on for specific controls. In short, it was an all or nothing approach. With ASP.NET 4.0,
the new ViewStateMode property gives you more control. It allows you to disable ViewState globally either on
the page or web.config level and then turn it back on for specific controls that might need it. ViewStateMode only works when EnableViewState="true" on
the page or web.config level (which is
the default). You can then use ViewStateMode of Disabled, Enabled or Inherit to control
the ViewState settings on
the page. If you’re shooting for minimal ViewState usage,
the ideal situation is to set ViewStateMode to disabled on
the Page or web.config level and only turn it back on particular controls: <%@Page Language="C#" CodeBehind="WebForm2.aspx.cs" Inherits="Westwind.WebStore.WebForm2" ClientIDMode="Static" ViewStateMode="Disabled" EnableViewState="true" %> <!-- this control has viewstate --> <asp:TextBox runat="server" ID="txtName" ViewStateMode="Enabled" /> <!-- this control has no viewstate - it inherits from parent container --> <asp:TextBox runat="server" ID="txtAddress" /> Note that
the EnableViewState="true" at
the Page level isn’t required since it’s
the default, but it’s important that
the value is true. ViewStateMode has no effect if EnableViewState="false" at
the page level.
The main benefit of ViewStateMode is that it allows you to more easily turn off ViewState for most of
the page and enable only a few key controls that might need it. For me personally, this is a perfect combination as most of my WebForm apps can get away without any ViewState at all. But some controls - especially third party controls - often don’t work well without ViewState enabled, and now it’s much easier to selectively enable controls rather than
the old way, which required you to pretty much turn off ViewState for all controls that you didn’t want ViewState on. Inline HTML Encoding HTML encoding is an important feature to prevent cross-site scripting attacks in data entered by users on your site. In order to make it easier to create HTML encoded content, ASP.NET 4.0 introduces a new Expression syntax using <%: %> to encode string values.
The encoding expression syntax looks like this: <%: "<script type='text/javascript'>" + "alert('Really?');</script>" %> which produces properly encoded HTML: <script type='text/javascript' >alert('Really?');</script> Effectively this is a shortcut to: <%= HttpUtility.HtmlEncode( "<script type='text/javascript'>" + "alert('Really?');</script>") %> Of course
the <%: %> syntax can also evaluate expressions just like <%= %> so
the more common scenario applies this expression syntax against data your application is displaying. Here’s an example displaying some data model values: <%: Model.Address.Street %> This snippet shows displaying data from your application’s data store or more importantly, from data entered by users. Anything that makes it easier and less verbose to HtmlEncode text is a welcome addition to avoid potential cross-site scripting attacks. Although I listed Inline HTML Encoding here under WebForms, anything that uses
the WebForms rendering engine including ASP.NET MVC, benefits from this feature. ScriptManager Enhancements
The ASP.NET ScriptManager control in
the past has introduced some nice ways to take programmatic and markup control over script loading, but there were a number of shortcomings in this control.
The ASP.NET 4.0 ScriptManager has a number of improvements that make it easier to control script loading and addresses a few of
the shortcomings that have often kept me from using
the control in favor of manual script loading.
The first is
the AjaxFrameworkMode property which finally lets you suppress loading
the ASP.NET AJAX runtime. Disabled doesn’t load any ASP.NET AJAX libraries, but there’s also an Explicit mode that lets you pick and choose
the library pieces individually and reduce
the footprint of ASP.NET AJAX script included if you are using
the library. There’s also a new EnableCdn property that forces any script that has a new WebResource attribute CdnPath property set to a CDN supplied URL. If
the script has this Attribute property set to a non-null/empty value and EnableCdn is enabled on
the ScriptManager, that script will be served from
the specified CdnPath. [assembly: WebResource( "Westwind.Web.Resources.ww.jquery.js", "application/x-javascript", CdnPath = "http://mysite.com/scripts/ww.jquery.min.js")] Cool, but a little too static for my taste since this value can’t be changed at runtime to point at a debug script as needed, for example. Assembly names for loading scripts from resources can now be simple names rather than fully qualified assembly names, which make it less verbose to reference scripts from assemblies loaded from your bin folder or
the assembly reference area in web.config: <asp:ScriptManager runat="server" id="Id" EnableCdn="true" AjaxFrameworkMode="disabled"> <Scripts> <asp:ScriptReference Name="Westwind.Web.Resources.ww.jquery.js" Assembly="Westwind.Web" /> </Scripts> </asp:ScriptManager>
The ScriptManager in 4.0 also supports script combining via
the CompositeScript tag, which allows you to very easily combine scripts into a single script resource served via ASP.NET. Even nicer: You can specify
the URL that
the combined script is served with. Check out
the following script manager markup that combines several static file scripts and a script resource into a single ASP.NET served resource from a static URL (allscripts.js): <asp:ScriptManager runat="server" id="Id" EnableCdn="true" AjaxFrameworkMode="disabled"> <CompositeScript Path="~/scripts/allscripts.js"> <Scripts> <asp:ScriptReference Path="~/scripts/jquery.js" /> <asp:ScriptReference Path="~/scripts/ww.jquery.js" /> <asp:ScriptReference Name="Westwind.Web.Resources.editors.js" Assembly="Westwind.Web" /> </Scripts> </CompositeScript> </asp:ScriptManager> When you render this into HTML, you’ll see a single script reference in
the page: <script src="scripts/allscripts.debug.js" type="text/javascript"></script> All you need to do to make this work is ensure that allscripts.js and allscripts.debug.js exist in
the scripts folder of your application - they can be empty but
the file has to be there. This is pretty cool, but you want to be real careful that you use unique URLs for each combination of scripts you combine or else browser and server caching will easily screw you up royally.
The script manager also allows you to override native ASP.NET AJAX scripts now as any script references defined in
the Scripts section of
the ScriptManager trump internal references. So if you want custom behavior or you want to fix a possible bug in
the core libraries that normally are loaded from resources, you can now do this simply by referencing
the script resource name in
the Name property and pointing at System.Web for
the assembly. Not a common scenario, but when you need it, it can come in real handy. Still, there are a number of shortcomings in this control. For one,
the ScriptManager and ClientScript APIs still have no common entry point so control developers are still faced with having to check and support both APIs to load scripts so that controls can work on pages that do or don’t have a ScriptManager on
the page.
The CdnUrl is static and compiled in, which is very restrictive. And finally, there’s still no control over where scripts get loaded on
the page - ScriptManager still injects scripts into
the middle of
the HTML markup rather than in
the header or optionally
the footer. This, in turn, means there is little control over script loading order, which can be problematic for control developers. MetaDescription, MetaKeywords Page Properties There are also a number of additional Page properties that correspond to some of
the other features discussed in this column: ClientIDMode, ClientTarget and ViewStateMode. Another minor but useful feature is that you can now directly access
the MetaDescription and MetaKeywords properties on
the Page object to set
the corresponding meta tags programmatically. Updating these values programmatically previously required either <%= %> expressions in
the page markup or dynamic insertion of literal controls into
the page. You can now just set these properties programmatically on
the Page object in any Control derived class on
the page or
the Page itself: Page.MetaKeywords = "ASP.NET,4.0,New Features"; Page.MetaDescription = "This article discusses
the new features in ASP.NET 4.0"; Note, that there’s no corresponding ASP.NET tag for
the HTML Meta element, so
the only way to specify these values in markup and access them is via
the @Page tag: <%@Page Language="C#" CodeBehind="WebForm2.aspx.cs" Inherits="Westwind.WebStore.WebForm2" ClientIDMode="Static" MetaDescription="Article that discusses what's new in ASP.NET 4.0" MetaKeywords="ASP.NET,4.0,New Features" %> Nothing earth shattering but quite convenient. Visual Studio 2010 Enhancements for Web Development For Web development there are also a host of editor enhancements in Visual Studio 2010. Some of these are not Web specific but they are useful for Web developers in general. Text Editors Throughout Visual Studio 2010,
the text editors have all been updated to a new core engine based on WPF which provides some interesting new features for various code editors including
the nice ability to zoom in and out with Ctrl-MouseWheel to quickly change
the size of text. There are many more API options to control
the editor and although Visual Studio 2010 doesn’t yet use many of these features, we can look forward to enhancements in add-ins and future editor updates from
the various language teams that take advantage of
the visual richness that WPF provides to editing. On
the negative side, I’ve noticed that occasionally
the code editor and especially
the HTML and JavaScript editors will lose
the ability to use various navigation keys like arrows, back and delete keys, which requires closing and reopening
the documents at times. This issue seems to be well documented so I suspect this will be addressed soon with a hotfix or within
the first service pack. Overall though,
the code editors work very well, especially given that they were re-written completely using WPF, which was one of my big worries when I first heard about
the complete redesign of
the editors. Multi-Targeting Visual Studio now targets all versions of
the .NET framework from 2.0 forward. You can use Visual Studio 2010 to work on your ASP.NET 2, 3.0 and 3.5 applications which is a nice way to get your feet wet with
the new development environment without having to make changes to existing applications. It’s nice to have one tool to work in for all
the different versions. Multi-Monitor Support One cool feature of Visual Studio 2010 is
the ability to drag windows out of
the Visual Studio environment and out onto
the desktop including onto another monitor easily. Since Web development often involves working with a host of designers at
the same time - visual designer, HTML markup window, code behind and JavaScript editor - it’s really nice to be able to have a little more screen real estate to work on each of these editors. Microsoft made a welcome change in
the environment. IntelliSense Snippets for HTML and JavaScript Editors
The HTML and JavaScript editors now finally support IntelliSense scripts to create macro-based template expansions that have been in
the core C# and Visual Basic code editors since Visual Studio 2005. Snippets allow you to create short XML-based template definitions that can act as static macros or real templates that can have replaceable values that can be embedded into
the expanded text.
The XML syntax for these snippets is straight forward and it’s pretty easy to create custom snippets manually. You can easily create snippets using XML and store them in your custom snippets folder (C:\Users\rstrahl\Documents\Visual Studio 2010\Code Snippets\Visual Web Developer\My HTML Snippets and My JScript Snippets), but it helps to use one of
the third-party tools that exist to simplify
the process for you. I use SnippetEditor, by Bill McCarthy, which makes short work of creating snippets interactively (http://snippeteditor.codeplex.com/). Note: You may have to manually add
the Visual Studio 2010 User specific Snippet folders to this tool to see existing ones you’ve created. Code snippets are some of
the biggest time savers and HTML editing more than anything
deals with lots of repetitive tasks that lend themselves to text expansion. Visual Studio 2010 includes a slew of built-in snippets (that you can also customize!) and you can create your own very easily. If you haven’t done so already, I encourage you to spend a little time examining your coding patterns and find
the repetitive code that you write and convert it into snippets. I’ve been using CodeRush for this for years, but now you can do much of
the basic expansion natively for HTML and JavaScript snippets. jQuery Integration Is Now Native jQuery is a popular JavaScript library and recently Microsoft has recently stated that it will become
the primary client-side scripting technology to drive higher level script functionality in various ASP.NET Web projects that Microsoft provides. In Visual Studio 2010,
the default full project template includes jQuery as part of a new project including
the support files that provide IntelliSense (-vsdoc files). IntelliSense support for jQuery is now also baked into Visual Studio 2010, so unlike Visual Studio 2008 which required a separate download, no further installs are required for a rich IntelliSense experience with jQuery. Summary ASP.NET 4.0 brings many useful improvements to
the platform, but thankfully most of
the changes are incremental changes that don’t compromise backwards compatibility and they allow developers to ease into
the new features one feature at a time. None of
the changes in ASP.NET 4.0 or Visual Studio 2010 are monumental or game changers.
The bigger features are language and .NET Framework changes that are also optional. This ASP.NET and tools release feels more like fine tuning and getting some long-standing kinks worked out of
the platform. It shows that
the ASP.NET team is dedicated to paying attention to community feedback and responding with changes to
the platform and development environment based on this feedback. If you haven’t gotten your feet wet with ASP.NET 4.0 and Visual Studio 2010, there’s no reason not to give it a shot now -
the ASP.NET 4.0 platform is solid and Visual Studio 2010 works very well for a brand new release. Check it out. © Rick Strahl, West Wind Technologies, 2005-2010Posted in ASP.NET
