Hi readers,

It’s been a long time since I last updated this blog. The reason is that I am no longer working with my fellow Southies. Although it was an outstanding experience to work with such a group of talented and can-do attitude people, it came that time for me where I wanted to explore other areas of my career. I know for a fact that I will work with them in the future, because I really respect them as professionals, and became good friends with most of the bunch.

Now, what’s important for most of my audience, is that I now found a host to continue my blogging experiences. You can find me at:


New RSS: http://feeds.feedburner.com/jdom

This blog (blogs.southworks.net/jdominguez) will be closed from now own. I hope to see you soon there!


Progressive Enhancement

February 19th, 2010

Progressive Enhancement (PE) is an approach for building Web Applications that starts from the perspective that a user browser experience will support a minimum functionality, this is called base line, but has hooks to allow functional enhancements when a browser can support them. PE benefits users by supporting older browsers, but also supporting users with modern browsers and technologies by providing them an improved experience.

The progressive enhancement and its counterpart, Graceful Degradation, are approaches that can help rich Web Applications support more browsers and have a wider reach.

Disclaimer: We are writing this documentation as part of the new Web Client Guidance that is being done in patterns & practices. We are close to finishing this project, so I would like to get more feedback or validation from everyone that gets the chance to read this before we release. Have in mind that the content of this topic can change both in content and in form (it can change because of YOUR feedback).

Progressive Enhancement vs. Graceful Degradation

Graceful degradation is the practice of building an application for modern browsers while ensuring it remains functional in older browsers and other user agents (for example, accessibility tooling and mobile devices).

Progressive enhancement is usually preferable to graceful degradation: it starts with the simple basics and improves usability and aesthetics on top of that. When developing using Progressive enhancement you should define a development base, for example when using MVC the base could be a user that does not have JavaScript enabled. Therefore, the expectation is that you should have the basic functionality available without JavaScript; but with JavaScript, the experience is richer, including functionality, such as client-side form validation, predictive fetching, and preview.

It is strongly recommended to use progressive enhancement, when designing something from scratch. Graceful degradation can be tedious, difficult and requires more work to implement.

However, if you are maintaining an existing site, the easiest choice is to provide graceful degradation, unless you want to rewrite the whole site.

It is also possible to combine both approaches in the application. Even some features may end up being the same, independent of the approach used.

Note: For more information about both concepts, see Progressive Enhancements and Graceful Degradation: Making a Choice.

Core Principles

  • Progressive Enhancement consists of the following core principles:
  • The basic content should be accessible to all browsers
  • The basic functionality should be accessible to all browsers
  • Semantic markup contains all content
  • Enhanced layout is provided by externally linked CSS
  • Enhanced behavior is provided by unobtrusive, externally linked JavaScript
  • End user browser preferences are respected

There are several scenarios to consider for using these patterns:

  1. Browsers that have JavaScript turned off
  2. Different browsers that:
    1. implement JavaScript and DOM features differently
    2. implement CSS differently
  3. The need for SEO (Search Engine Optimization)

Browsers that Have JavaScript Turned Off

Browsers may have JavaScript disabled due to company policies, screen readers, or other accessibility issues. This is usually the biggest challenge of all, as it requires the most development effort. If it is not done correctly, it could prevent the user from interacting with the site at all.

To address this scenario, you should start developing the site using HTML for the basic content. You should use semantic markup and CSS to enhance the layout. Then you should start adding functionality for browsers that do support JavaScript and other client technologies.

The following are some advantages and disadvantages of creating applications without JavaScript.


  • Can support browsers without JavaScript
  • It is SEO friendly (as search engine spiders do not use JavaScript)
  • Easier to create an accessible site as a side effect without too much effort
  • Possibility to open links in new tabs and bookmark it (for example if you use the middle mouse, it will open the link in href instead of executing the JavaScript defined for the click event).


  • There is usually a need to create a server-side version of a view, and a separate client version of the same view or portions of it.

The developer has to be aware of the scripted and non-scripted features of the application, instead of just assuming that JavaScript will always be present.

Different Browsers that Implement JavaScript and DOM Features Differently

This challenge is typically known as cross-browser incompatibility. Compared to the previous scenario, when not implemented successfully, might prevent the user from interacting with the site in some cases, which causes frustration for the user, or even breaking JavaScript functionality completely, and cause a situation similar to the previous scenario.

This challenge has been a major pain point for web developers in past years, which led to using mostly server-side controls made by expert web developers that emit islands of JavaScript automatically, in order to prevent the application developer to have to learn all the browser differences, which in turn led to application developers from getting away from learning any JavaScript at all, even for simple tasks.

In recent years several JavaScript libraries have emerged that provide a cross browser experience for all of the most common tasks. By writing your code on top of these base libraries, in most cases you can avoid dealing with branching logic for the different browsers, which leads to a better appealing to the JavaScript language as a renewed development tool.

Different Browsers that Implement CSS Differently

CSS differences between browsers, though it is generally good to account for, it is usually not a big problem if bypassed. The reason is that having CSS that do not work in all browsers might cause some browsers to render the page with some inconsistencies in sizes, placement, overlapping of sections, but this will generally not prevent the user from interacting with the site entirely.

The following are some tips for dealing with these CSS inconsistencies:

  • Use a CSS reset, which improve a lot of the cross-browser inconsistencies in size, placement, and overlapping issues.
  • Develop the site with standards in mind (consider targeting XHTML 1.0 Transitional here), which almost always works in IE8, Firefox, Safari, Chrome, and usually Opera.
  • If the standards targeted HTML/CSS has IE6/7 issues, fix those issues by including CSS “hacks” in separate stylesheets referenced through conditional comments.

It is up to the business to decide the ROI for creating a site that looks identical across all the browsers. Because not supporting all versions of CSS implementations will not prevent users from interacting with your site, you could typically decide to support the CSS features in the browsers with the largest market shares, while ignoring older browsers.

How to Achieve Progressive Enhancement

To implement PE you should begin with the basic version, and then add enhancements for those browsers that can handle them.

First, you should start developing your application in plain HTML. Plain HTML is understood by all browsers. Furthermore, search spiders will be able to access and index your site content.

This also means that all anchors and forms must have a working target URL for navigating or posting data without the need for JavaScript.

Then, add styles using CSS in an external file to improve the look and feel of the site. Almost all browsers support CSS, and those which do not support it, will simply ignore the styling.

Finally, add JavaScript support, using unobtrusive JavaScript. Unobtrusive scripts are silently ignored by browsers that do not support JavaScript, but it is applied by those that do it.

Unobtrusive JavaScript separates content from behavior. This means you should avoid having inline JavaScript as in the following example.

<form id=”profile” action=”http://mySite.com/SaveProfile”>
  <input type=”text” name=”age” />
  <input type=”submit” value=”Save” onclick=”SaveProfileWithAjax();” />

This is because the purpose of markup is to describe a document’s structure, not its programmatic behavior.

The unobtrusive solution is to register the necessary event handlers programmatically, rather than inline. This is commonly achieved by assigning a particular CSS selector to all elements which are affected by the script, to reduce the amount of script code. The JavaScript code should reside in a separate file. In the following code the id attribute is used for identifying a form:

<form id=”profile” action=”http://mySite.com/SaveProfile”>
  <input type=”text” name=”age” />
  <input type=”submit” value=”Save” />

It is recommended that you use libraries that provide an abstraction of the DOM. The jQuery and ASP.NET Ajax libraries do a good job at this.

The following jQuery script binds the submit event of the form with id=”profile”, to the SaveProfileWithAjax function:

Note: jQuery simplifies this, by providing a CSS-like selector, instead of just getting the elements by ID.

JavaScript using jQuery
$(document).ready(function(){ //Wait for the page to load.
    $(‘form#profile’).bind(‘submit’, SaveProfileWithAjax);

function SaveProfileWithAjax(event){
    event.preventDefault(); // this will prevent the browser for submitting the form in the default way, as we will handle the post programmatically using AJAX
    // Post the data using an AJAX call

Note: The event.preventDefault JavaScript method cancels the event if it is cancelable, meaning any default action normally taken by the implementation as a result of the event will not occur.

The following code shows the implementation in ASP.NET Ajax Library.

JavaScript using ASP.NET Ajax Library
Sys.Application.add_init(function() {
    $addHandler($get(‘#profile’), ‘submit’, SaveProfileWithAjax);

function SaveProfileWithAjax(event){
    // Post the data using an AJAX call

Note: To attach events, modern browsers use the addEventListener function specified in the DOM Level 2 (Events) specification, while Internet Explorer will use its proprietary attachEvent function. For this reason, if you want to achieve cross-browser compatibility in a simple manner, you should always attach events using a library like jQuery or ASP.NET Ajax Library, which automatically deals with these compatibility issues.

Tips for Achieving Progressive Enhancement in ASP.NET MVC

Consider the following tips when implementing the progressive enhancement pattern in ASP.NET MVC.

First, build an HTML feature that works without JavaScript. For example, the song rating functionally of the Reference Implementation, which was created using radio buttons.

The following rules are applied to every web application (not just ASP.NET MVC ones) to achieve PE.

  1. Use semantic markup to render the basic content.
  2. Use CSS to enhance the layout.
  3. Anchors should always have the href attribute set to return a working view from a controller.
  4. Forms should always have the action attribute set to post the data to a working action in a controller, based on the input elements in the form. Consider rendering hidden inputs for preset values that the users don’t need to update or see.

Once the basic functionality works without JavaScript, consider the following:

  1. Enhance the experience using Unobtrusive JavaScript. This typically includes:
    • Adding client-side validation to acquire immediate feedback without requiring a full post.
    • Converting full page POST/GET requests into AJAX calls that update portions of the page.
    • Adding animations / eye candy features.
  2. When converting a full page request into an AJAX call, hijack and prevent the default action of the anchor link or form submit, and replace it with the AJAX call. You typically do this by calling the preventDefault method of the arguments object received when handling the click/submit event using JavaScript.
  3. Avoid having different URLs for accomplishing the same business result for these cases. You can add branching code in your controller that checks the Request’s headers to see if it is an AJAX call as opposed to a typical GET or POST call, and return a different result in this case.
    • Typical approaches include returning partial HTML markup to be inserted without processing into the DOM, or data represented in JSON that requires some processing in the browser to display it.
    • ASP.NET MVC provides a standard way of checking if the request was initiated using XmlHttpRequest by calling the Request.IsAjaxRequest() extension method
      Note: If you use ASP.NET WebForms instead of ASP.NET MVC, you might need to create different endpoints, such as Web Services, ASP.NET Page Methods, or even expose MVC controllers for these actions, as there is no easy way of reusing the same endpoint, because a URL maps to a physical ASPX file.
  4. In the cases where you return JSON, you might need to use JavaScript to directly manipulate the DOM, or when possible, have a template view that renders data that was retrieved in JSON format. Having templates can help you better separate UI logic from the model in the JavaScript code. The ASP.NET Ajax Library has a very good templating engine that allows you to bind to a ViewModel in a somewhat similar way as WPF & Silverlight. For more information, see Isolating the Domain Model from the Presentation Layer (this is in the Web Client Guidance documentation).
  5. In some cases, you may have DOM elements that only make sense in a non-JavaScript version of the page. This is common, and you might want to remove these elements by using JavaScript if it is available in the browser.
    For example, you may have a link that redirects to a different page, but when you enhance it with JavaScript, you might hide those links entirely, and replace it with a much richer experience that does not require a redirect for example.
    Note: You can also use the noscript HTML element to render content when JavaScript is not enabled or not supported by your browser.
  6. Cascading drop-downs is another canonical example: If you have a State drop down, that once selected will set available cities in another drop-down, the non-JavaScript version will have a visible submit button, and so after setting the State, the user can POST back to the server and get the same page with the available cities already populated. When JavaScript is enabled, after the page is loaded, you might want to hide this button, and on selection change of the State dropdown, request the available cities with an AJAX call that returns JSON, and update the dependant Cities dropdown. There is no need for the user to explicitly click the button to get the cities.

Finally, move on to the next feature. Remember, to always build a non-JavaScript version of a feature, and enhance it afterwards. There might be secondary features in the application where you can decide to implement in browsers that only have JavaScript enabled, but you should make this decision consciously, identifying the risks for not supporting that scenario.


More Web Client Guidance

You can find this and many other topics and key decisions for creating web client applications (both in ASP.NET Web Forms and ASP.NET MVC) in our latest Web Client Guidance drops. We are close to finishing this guidance, so your prompt feedback is invaluable to us. Make sure you check it out and comment in this topic or in the codeplex forums (there is a special tag to mark conversations for this new guidance)

kick it on DotNetKicks.com Shout it


Typically, the user interface in Web Applications is composed of multiple pages. Now with the increasing popularity of AJAX, it is common that people want to develop Web applications that are similar and provide the same user experience as desktop applications. One common problem in Web applications is the constant page reloads and flickering when navigating the application.

Disclaimer: We are writing this documentation as part of the new Web Client Guidance that is being done in patterns & practices. We are close to finishing this project, so I would like to get more feedback or validation from everyone that gets the chance to read this before we release. Have in mind that the content of this topic can change both in content and in form (it can change because of YOUR feedback).


Any of the following conditions suggest using the solution described in this pattern:

  • You want to minimize the page reloads and flickering when navigating through the application.
  • You want to change only the content of the page and maintain the general layout; that is the header, footer, and menus, when updating the page.
  • You want the user to keep the context of most of the page, while only manipulating the data on part of the page.
  • You want to have long running processes and/or avoid losing/refreshing dynamic content state while navigating (for example, uploading files or a chat window).
  • You want to improve the user experience of Web applications, by simulating the look and feel, and usability of desktop applications.


Have all of your page features, or at least most of them, in a single page. This is known as the Single-Page Interface (SPI) model. In the SPI model, all browser interactions with a Web application occur inside the boundaries of one page.

The SPI pattern improves the UI navigability of Web applications because it decreases the number of page reloads and eliminates flickering.

The SPI model requires a number of highly interactive features, which include in-place editing, context-sensitive user interface, immediate user feedback prompts, and asynchronous operations.

The Single-page Interface pattern elements



SPI is an AJAX pattern that suggests you have only a main page in your Web Application. This page interface is rearranged as a result of user interaction with the application.

Having a single-page interface, may result in your application using less-distinct URLs. Therefore, this pattern may not provide good support for search engines, unless explicit mechanisms for also allowing the navigation of the site by using full redirects are implemented.


The Single-page Interface pattern has the following liabilities:

  • As all interactions occur within a page, there are less distinct URLs. Therefore, this pattern does not inherently provide good support for search engines
  • You need to implement a mechanism to identify the different states of the application; this is for providing history browsing support and bookmarking. It might be used also for supporting permanent link. Unique URLs and deep linking can be supported in an SPI app but with additional development cost. Web applications built using more traditional full page refreshes support unique URLs and deep linking more easily.
  • You have to be careful with memory leaks, because as the page is not refreshed as often, the memory is not cleaned automatically by the browser. Therefore you have to manually dispose objects, handlers, and so on, when navigating through the page.
  • The SPI pattern requires a lot of JavaScript. If JavaScript is turned off, the user will not be able to use the application. This then requires down-level support in addition to the SPI pattern. It makes more sense to implement the SPI pattern if you have more control of your browsers, for example, if you have an intranet application and you know the corporate image does not restrict JavaScript, then SPI might work here. For the Internet case, it is more mixed because some users will enable JavaScript and some will not.
  • Consider using the Progressive Enhancement or Graceful Degradation pattern, for addressing accessibility, browsers where JavaScript is disabled, and search engine optimization. Otherwise older browsers or readers will not be able to use your application. If you choose to support accessing the website without the use of JavaScript, the complexity of the application increases exponentially, as you would typically need to create server and client side version of most of the views. This approach can also help to add better support for search engines.

Identifying the State of an Application with Distinct URLs

When using AJAX and the SPI pattern, an application may perform different operations, and therefore pass through different states while the URL in the browser stays constant. This creates the need of a mechanism to identify different states of the application, for example, for moving back to a previous state.

Browsers implement the Back and Forward buttons functionality by caching the list of visited URLs.

In AJAX, the server communication is done through XMLHttpRequests, and these requests do not change the page URL. Therefore, the list of visited URLs is not modified.

The Unique URLs pattern helps addressing this problem, by assigning a unique and expressive URL to each significant application state.

Scripting does not provide a mechanism to modify the list of visited URLs, but it provides mechanisms to modify the URLs.

You can manipulate the URL with JavaScript using the window.location.href property, but this will trigger a page reload; fortunately you can use the window.location.hash property. The hash property is used for fragment identifiers, which are optional components of URLs that came after the hash character (#). The string that comes after the hash character is not sent to the server; therefore, the browser is responsible for restoring the state through client scripts, and retrieving the appropriate views. Because they are like normal links, but within a single page, no page reload occurs, and the browser behaves as if you have clicked a standard link, adding the URLs to the list of visited URLs. This also enables history navigation, bookmarking and sharing URLs with other people.

Note: Setting the hash property does not work reliably on all browsers, and you do not get change notifications on all browsers either. For this reason, it is recommended using some library that handles these differences in a cross-browser way, such as the Microsoft Ajax Library History control.

Therefore, when there is an important state change in your application, modify the URL hash property. In this way the changes will be tracked by the browser.

window.location.hash = stateData;

The resulting URL will look like the following.


Once you have identified each relevant state of the application, you need to implement code to parse the URL. You can choose the format based on your specific needs to represent a state, you can even add parameters in the URL, as seen in the following example.


Finally, after parsing the URL, you should restore the application to the corresponding state based on the hash data, keep in mind that the hash data is not sent to the server as part of the URL. In the previous example, when loading that URL, the application should go to the product details form, showing the details of the product with ID 5529.

More Information

For more information about the Single-Page Interface pattern, see the following:

For more information about software design patterns applied in the Web Client Guidance, see Patterns in the Web Client Guidance.

You can find this and many other topics and key decisions for creating web client applications (both in ASP.NET Web Forms and ASP.NET MVC) in our latest Web Client Guidance drops. We are close to finishing this guidance, so your prompt feedback is invaluable to us. Make sure you check it out and comment in this topic or in the codeplex forums (there is a special tag to mark conversations for this new guidance).

kick it on DotNetKicks.com Shout it

I get this question very often. Should I you the one or the other?
Well, my short answer in most circumstances is “you should use both“.
My long answer is “it depends on what you are trying to achieve”, and this blog post will try to cover what are the strengths of each of the libraries, and also why it’s OK to use both with the overhead this “might” have.

ASP.NET Ajax Library vs jQuery functionality overlap

Disclaimer: We are writing this documentation as part of the new Web Client Guidance that is being done in patterns & practices. We are close to finishing this project, so I would like to get more feedback or validation from everyone that gets the chance to read this before we release. Have in mind that the content of this topic can change both in content and in form (it can change because of YOUR feedback).
Also, this topic was created using ASP.NET Ajax Library 0911 beta and jQuery 1.3.2.

Guidelines for using ASP.NET Ajax Library and jQuery

There are different JavaScript libraries that can assist you in authoring JavaScript code that runs on the browser, and using at least one of them is an absolute must in today’s environment. Though ASP.NET WebForms is better suited -but not limited to- for using the ASP.NET Ajax Library, ASP.NET MVC has no preference over either ASP.NET Ajax Library, jQuery or other 3rd party libraries. Furthermore, ASP.NET Ajax Library and jQuery can work especially well together and complement each other, whether you render markup using WebForms or MVC.

ASP.NET Ajax Library and jQuery can be used together in the same Web application, and they both have support from Microsoft. These libraries do not conflict with each other, but they complement each other greatly. The overlap between functionality is not big, and since jQuery’s official support by Microsoft, this overlap is getting reduced in every release.

ASP.NET Ajax Library has made important changes to its core to leverage jQuery functionality when it detects that jQuery is also loaded. For example, ASP.NET Ajax Library provides some basic jQuery-like selector support for selecting DOM elements for its Sys.get(selector) method, which is used internally by many other components. Nevertheless, when jQuery is available, the selector passed into this method can be very complex, because it will delegate the DOM selection to jQuery under the hoods.  Furthermore, all ASP.NET Ajax Library controls and plugins, are also exposed automatically as jQuery plugins.

We found that in most cases, although there is an additional cost for downloading the 2 libraries instead of just one, the productivity and features covered by both libraries working together far outweighs that cost. Also, keep in mind, that if your application is hosted in the internet, as opposed to an Intranet, it is strongly recommended that you use the Microsoft CDN, so the download time gets reduced, and sometimes skipped, as the files may be cached by the browser.

The following sections define some pros that we found when using a particular library over the other. This list should not be taken as completely objective or closed, as depending on what plugins you decide to use, there might be advantages or disadvantages for each. These guidelines are based on the experience developed by using both ASP.NET Ajax Library and jQuery when building web applications in the last few months, as Microsoft has recently added support for jQuery from within Visual Studio, and the ASP.NET Ajax Library has taken huge steps towards supporting both libraries side by side.

Why should you use jQuery

One of the more important reasons for using jQuery is for DOM (Document Object Model) manipulation.

  • The jQuery library is extremely easy to use for finding elements using selectors, for moving elements to different locations inside the DOM, changing element classes, basic animations, and so on.
  • jQuery has a simple API for handling DOM events. However, this functionality is comparable to what can be accomplished with ASP.NET Ajax Library. Due to this, in the Reference Implementations both approaches are used interchangeably; depending on what was the handling logic being used for (that is, DOM manipulation, controlling logic, and so on).

Another strong point of jQuery is the Developer community behind it.

  • Because jQuery supports only client-side functionality, it is server-side technology agnostic, and has a powerful extension mechanism.
  • For the previous reasons, it has been more widely used to develop plugins for a lot of different situations. These plugins are available through the official jQuery site, although each of them has its own license. Nevertheless, a big percentage of these plugins use very permissive open source licenses, an most of them use the same license as the jQuery core, to ease adoption for users who are already using jQuery.

Why should you use the ASP.NET Ajax Library

We found the ASP.NET Ajax Library to be especially useful for writing JavaScript logic whose objective was not just manipulating or animating the DOM. Also, the script loading capabilities was of great help in both the perceived performance of the application and in the development and organization of the JavaScript code.

Some other strong points of the ASP.NET Ajax Library are the following:

  • API and syntax similar to the .NET framework. The library imitates the .NET framework API, type system and namespaces hierarchies, therefore the developers familiar with the .NET framework can learn this framework with ease.
  • The Ajax Script Loader that comes with the library is useful for loading scripts in parallel and for managing dependencies. Using the Script Loader gives you the following advantages.
    • Minimize an Ajax application’s render time
    • Handle loading script dependencies
    • Leverage script combining techniques
    • Perform lazy loading of scripts behind the scene

Note: For more information about the ASP.NET Ajax Library Script Loader, there is a specialized Script Loading document in the Web Client Guidance, make sure to check it out.

  • It is especially useful for writing logic that does not only manipulate the DOM. It provides infrastructure for creating JavaScript controls and behaviors (extending the Sys.Component type), and also provides memory management, easy control creation/instantiation.
  • You can use Client Templates to bind the UI to an observable view model. This allows separating the concerns of UI specific code (or DOM manipulation) from the presentation logic. This also simplifies unit testing the JavaScript code by avoiding the need to test the DOM state and user interaction directly.
  • Browser history:  When the state of a web page changes by using Ajax calls to the server, the URL in the browser does not change automatically. The ASP.NET Ajax Library simplifies working with the browser history, with a cross-browser approach.
  • The Ajax Control Toolkit is a set of reusable controls that can be used from both ASP.NET Ajax Library and jQuery using JavaScript code, and is also very friendly for using it from server-side generated JavaScript, especially when using ASP.NET WebForms server controls.
  • It provides auto-generated proxy classes that simplify calling Web service methods from client scripts.
  • When using ASP.NET WebForms, the ASP.NET Ajax Library is the easiest to use in several scenarios, as many of the controls and functionality can be used from their server-side controls counterparts.
  • Working with ADO.NET Data Services is very easy with the ASP.NET Ajax Library. This, in combination with Client Templates can help creating client side views that consume data from the server very easy.


More Web Client Guidance

You can find this and many other topics and key decisions for creating web client applications (both in ASP.NET WebForms and ASP.NET MVC) in our latest Web Client Guidance drops. We are close to finishing this guidance, so your prompt feedback is invaluable to us. Make sure you check it out and comment in this topic or in the codeplex forums (there is a special tag to mark conversations for this new guidance)

As some of you might probably know because of some posts by Blaine, the patterns & practices team that brought you Prism is working on a new Web guidance.

This project is currently under development, and as with all p&p assets, we opened up our biweekly drops to the community, so we can get early feedback from you.

Music Store Reference Implementation - Search Results

This all new Web guidance is not built on top of Web Client Software Factory, but can coexist with it. So if it’s not WCSF, and it is from the same group…

… what is this all about?

The anticipated benefits include (but might change in the final release, again, FEEDBACK is the magic keyword):

  • Provides infrastructure for developing and maintaining ASP.NET and AJAX applications
  • Provides guidance on MVC 2, jQuery, and AJAX library
  • Unit testing for ASP.NET and JavaScript client applications
  • Responsive applications
  • Flexible architecture that allows change
  • Separated presentation including unit testing view logic
  • Application modules are developed, tested and deployed separately
  • User Interface components are dynamically composed
  • Guidance on how to improve Web client security
  • Allows incremental adoption of the components

What is the current state?

This is the first public drop of the Web Client Developer Guidance. We are currently in the 5th iteration. The Reference Implementation (RI) shows several UI patterns (predictive fetch, preview, edit-in-line). Most recently, we’ve been working on implementing separated presentation patterns and composability within MVC. The RI has JavaScript unit tests using QUnit. Also included in the RI is guidance on minification and combining JavaScript files.

The 3 included QuickStarts are:

  • RI_WebForms. This is a port of the RI, developed using MVC, to Web Forms.
  • Validation QuickStart. This shows server and client-side validation.
  • WebFormsMVCHybrid. This shows MVC functionality within a Web Forms application.

The documentation includes draft guidance on cross-site scripting, cross-site request forgery, update panel, and more.

Bare with us that this is in a very early stage, so for example you might see a bad looking site, as we hadn’t hired a designer to enhance our CSS and so on (yup, us developers frequently pick colors from the combobox, and remember that the usual choices are Aqua, Magenta and so on :D).

How can I consume this?

There is a readme file included in the drop, that will tell you how to get the dependencies (they are just a few). It will also tell you how to run the RI or the JavaScript unit tests.

Once you are running the RI, you’ll see in each page a very last-minute-information-panel, that will tell you what we are demonstrating in each of the pages, from a technical perspective (expect improvements to this in future drops).

Now that this drop is out, I’ll be writing blog posts more frequently, to tell you about the decisions and hidden goodies we’ve found while developing.

Where is it?

Get it from codeplex! Current drop is the one from Nov 13th.

Remember, WE WANT FEEDBACK FROM YOU! (yes, we are not kindly asking, you can make the project be what you need, we just need to know what you think about it).

Shout it kick it on DotNetKicks.com

El evento online Windows Day: “Tecnologí­a para derribar paredes” acaba de empezar!

Windows Day

Para los que no saben de qué se trata este evento, una breve descripción tomada del blog del evento:

Descubre novedades acerca de las tecnologías de implementación, administración y de desarrollo de aplicaciones en desktops con Windows Vista y con Windows 7: cómo mejorar el rendimiento, cuándo virtualizar, cómo optimizar los escritorios, incrementar la seguridad, resolver el acceso a datos y cómo crear las mejores interfaces de usuario. Conoce todas las novedades que llegan con el SP2 de Windows Vista y lo que se viene con Windows 7 y ASP.NET 4.0. Conferencias online, demos y chat en vivo con expertos para dominar las últimas tecnologí­as en desarrollo de aplicaciones Windows (y web también).


Junto al gran Miguel Ángel Saez, estaremos presentando la siguiente sesión:

Sesión MSDN-1: Dando el salto hacia el presente con Windows Presentation Foundation

Conceptos necesarios para la creación de aplicaciones de negocio, que distinguen a WPF de otras tecnologías: Estilos, DataBinding, el patrón Presentation Model y los controles DataGrid y Ribbon.

Vamos a estar introduciendo Windows Presentation Foundation (WPF), haciendo hincapié sobre el lado técnico y de arquitectura de WPF, especialmente dirigido a desarrolladores que vienen de tecnologías clásicas como WinForms, y están tanteando la madurez de WPF como plataforma de aplicaciones de negocio.

También, como pueden ver de la descripción, y como no podía ser de otra manera, vamos a estar introduciendo el patrón Presentation Model, también conocido como Model-View-ViewModel (o M-V-VM), del cual ya he escrito varios posts en inglés.

Para la demostración del uso de este patrón, estaremos utilizando una versión simplificada de la aplicación de referencia de Prism (proyecto que les recomiendo mirar si piensan crear aplicaciones de negocio complejas): Stock Trader RI.

Prism 2.0 Stock Trader Reference Implementation


Las conferencias y demos son pre-grabadas, por lo que podrás verlas en el orden y en el momento que desees, y habrá más de 50 importantes expertos de todo Latinoamérica chateando contigo en las sesiones en vivo; y en exclusiva, una sesión en vivo con Mark Russinovich.

Accede al evento aquí­: http://www.microsoft.com/latam/windowsday/

Cualquier consulta, no duden en consultarme por medio de este blog. Espero que les resulte interesante y les haga dar el salto a WPF!

A week ago we announced the Composite Application Guidance for WPF and Silverlight – February 2009 release.

A few days after, Microsoft released a new version of Silverlight (version 2.0.40115.00 or just GDR1), and it broke a build script that we were using for some of the unit tests in the CAL. This didn’t prevent the users from using the CAL, but was causing build failures with cryptical error messages. You can read the full details here.

We also got feedback from users (i.e here, here and from Brian Noyes), that when migrating an existing Prism 1.0 app to Prism 2.0 (WPF), they were experimenting inconsistencies with the activation and deactivation of views when using a TabControl as a region. You can read the full details here.

We decided to fix both issues and refresh the download bits, so you can now download them from MSDN.


What files were updated in the source code?

If you are including the CAL in you application’s source control, you might want to know exactly what files were updated.

The following are the only files updated with this refresh:

  • CAL/Silverlight/Composite.Tests/Mocks/Modules/createXap.bat
  • CAL/Silverlight/Composite.Tests/Modularity/XapModuleTypeLoaderFixture.cs
  • CAL/Desktop/Composite.Presentation/Regions/Behaviors/SelectorItemsSourceSyncBehavior.cs
  • Desktop/Composite.Presentation.Tests/Regions/Behaviors/SelectorItemsSourceSyncRegionBehaviorFixture.cs


Do you have the latest version already?

If you are not sure whether you already have the latest version of the self-extractable EXE for the source code (because the version number was not updated) you can check the timestamp of the Digital Signature. The refreshed bits should read ‘Tuesday, February 24, 2009′ (don’t mind the time, as it varies with the time zone of the PC).



More info on the refresh on Blaine Wastell’s blog and Bob Brumfield’s blog.

Happy composite application building!

Great news guys: the Composite Application Guidance for WPF and Silverlight – February 2009 has been finally released.

You’ll be glad to know that the final version of this new release is out. If you’ve been playing with the bi-weekly drops, or holding off to be able to use this already embraced guidance from WPF, but in your Silverlight projects, you can now start grinning.

Intended Audience

This guidance is intended for software architects and software developers building enterprise Windows Presentation Foundation (WPF) or Silverlight applications. Such applications typically feature multiple screens, rich, flexible user interaction and data visualization, and role-determined behavior. Additionally, these applications typically use layered architectures that may be physically deployed across tiers, strong separation of concerns, and loosely coupled components. They are “built to last” and “built for change.” This means that the application’s expected lifetime is measured in years and that it will evolve in response to new, unforeseen requirements. Applications that do not demand these features and characteristics may not benefit from the Composite Application Library.

The Composite Application Guidance is not difficult to learn, but developers must be ready and willing to embrace patterns and practices that may be new to them.


Composite Application Guidance Assets

  • Composite Application Library source code. Developers can use the Composite Application Library to develop multi-targeted applications in WPF and Silverlight that are composed of independent and collaborating modules.
  • Unity Extensions for Composite Application Library source code. This provides components to use the Unity Application Block with the Composite Application Library.
  • Stock Trader Reference Implementation (Stock Trader RI). This is a composite application that is based on a real-world scenario. This intentionally incomplete application illustrates the composite application baseline architecture. This is a good reference to see how many of the challenges when building composite applications are addressed by this guidance.
  • QuickStarts. This includes the source code for several small, focused applications that illustrate a specific challenge.
  • Documentation. This includes the architectural overview, Stock Trader RI overview, design and technical concepts for composite applications, applied patterns, How-to topics, QuickStarts overviews, and deployment topics. Much of this guidance is applicable even if you are not using the Composite Application Library, but you just want to know best practices for creating composite applications.


What’s new from Prism 1.0

  • Silverlight Support. The complete Composite Application Library, RI, QuickStarts, documentation (everything!) has been brought into life in Silverlight. The source code is targeting both WPF and Silverlight, by using linked source code files (there is of course guidance on how to develop applications that reuse code for these 2 platforms if you are planning to target both of these with the same code).
  • WPF developers won’t see much difference in the Composite Application Library itself, but there are some reasons to update:
    • View Discovery UI Composition. Modules can register views (or presentation models) against a named region. When that region is displayed at run time, any views that have been registered for that location will be automatically created and displayed within it. The Prism 1.0 way of adding views to a region is now officially called View Injection, because it does not work as a configuration mechanism, but as a explicit demand to add the view into a specific region instance.
    • RegionContext is useful when you want to share context between a parent view and child views that are hosted in a region. Think of this like flowing DataContext down, but through regions.
    • ICommand attached behavior base. Base class to help create behaviors for control events that will fire an ICommand.  This was mostly done to support executing commands in Silverlight when clicking a button, but could be applied equally well to WPF for other kind of events (such as pressing the Enter Key on a search box as it’s being demonstrated in the RI). The basic idea around behaviors for ICommand is similar to what I blogged about in this post a while ago.
    • Region extensibility. Regions are easier to extend with their functionality moving into attached region behaviors.
    • Module Catalog. This concept is easier to understand and use than the Module Enumerator and Module Loader present in 1.0. Nevertheless, migrating to the catalog from enumerators is pretty straightforward and it’s explained in the docs.
  • Project Linker. Basic tooling that helps you keep 2 projects synchronized by creating Visual Studio file links from one project to another. This is useful for sharing source code that targets both WPF and Silverlight platforms (as there is no binary compatibility).

What is different between the Silverlight and the WPF version of the Composite Application Library in this release?

    The codebase is mostly the same, except for some minor differences. The biggest of these is that Directory Lookup of modules and Configuration based module catalog is available in WPF only, whilst Silverlight supports retrieving modules asynchronously in separate XAP files, to reduce the main application size (and startup time).



A new drop of Composite Application Guidance for WPF and Silverlight (or Prism) is out. Get it from Codeplex.

The latest changes since drop 6 include:

  • Modularity

Many changes where made to Modularity to keep it simpler (although not extremely noticeable for the surface API consumer).

We also re-included the Directory Lookup and Configuration based module enumerators for WPF (the ones that were included in Prism V1), and the respective QuickStarts that show their usages.


  • Commanding

We included the Commands namespace in Silverlight’s CAL.

In order to hook up an ICommand to a button from XAML, we are following a similar approach to what we’ve done in a previous spike and blogged about it here, so I won’t go into many details about it in this post.

The CommandParameter cannot be set from XAML currently; that feature did not make it in drop 7 for a few minutes, but this will definitely be possible in the next drop.

We also ported the Commanding QS to Silverlight, although this is still work in progress.


  • Regions

There is a breaking change in the Regions property of the IRegionManager, which may not be noticeable for the majority of users, but it can break some of your RegionManager mocks if you are doing TDD (and if you are not… WHY NOT?!?!? ;-) )

  • Documentation

Changes in the documentation includes explanation of the new Pull-based Composition QuickStart and the Modularity QuickStarts for WPF.

  • Project Linker

If you like ProjectLinker or you would like to try it, but didn’t feel like installing Visual Studio 2008 SDK, you will be happy to know that it does not require the SDK anymore :)

There is a separate download for the ProjectLinker installer and for its source code, as the latter still requires the SDK if you want to update it and build it yourself.

I hope you like it, and as usual, we are driven by the community, so your feedback is very useful to us.

The 6th drop for this project is already out of the team room and into Codeplex, as it has been every 2 weeks since 2*(6-1)=10 weeks back from today.

You can see the complete list of latest changes in Erwin’s post.


The biggest changes for this drop, although not very noticeable from the outside if you’re just using the default way that Regions work without the need to extend them, are:

  • Added RegionContext

This is to provide a way to pass some context to the Views that are placed inside a particular instance of a region. You were usually able to workaround the need for this context by using EventAggregator or scoped DI containers, but luckily this will be easier to achieve for those same scenarios and for more complex ones (for example when using scoped region managers and having several instances of the same region).

  • Formalized infrastructure for extending the behavior of Regions

In Prism 1.0 there were already some ad-hoc behavior classes for extending the functionality of the regions (for example the CollectionActiveAwareBehavior or SelectorRegionSyncBehavior).

In Prism V2, we also had to rethink how the RegionManager attached properties would work in the Silverlight world, as it is different from WPF (Silverlight lacks property value inheritance). We also added features like the new Pull-based composition scenario, or the RegionContext attached property.

We started adding separate behavioral objects for these new features, which were very flexible, but very hard to understand, debug, and to know which objects were currently modifying the behavior of a particular region instance.

This created the need for an infrastructure for all of these formerly independent behavior objects, that would make the library easier to understand, extend and maintain.

The IRegion interface now has a collection of IRegionBehavior objects, so you can always know which objects are extending the functionality of a particular Region instance, and it can also couple the lifetime for these behaviors and regions, in order to prevent memory leaks when developing new behaviors.

    RegionBehaviors infrastructure in Prism V2Picture taken from Erwin’s blog post. Read the full post here