We have just posted an updated version of Dynamic Data Futures on codeplex. The Dynamic Data Features project is a combination of a class library and sample website that showcases some of the future work that will be coming to Dynamic Data. It also contains some workarounds for existing Dynamic Data bugs and issues.

Here's a rough list of what is new from last week:

We have just posted an updated version of Dynamic Data Futures on codeplex. The Dynamic Data Features project is a combination of a class library and sample website that showcases some of the future work that will be coming to Dynamic Data. It also contains some workarounds for existing Dynamic Data bugs and issues.

Here's a rough list of what is new from last week:

Update: the Dynamic Data Futures was updated on 7/2.

We have just posted an updated version of Dynamic Data Futures (known for the last 10 days as Dynamic Data Extensions) on codeplex. The Dynamic Data Features project is a combination of a class library and sample website that showcases some of the future work that will be coming to Dynamic Data. It also contains some workarounds for existing Dynamic Data bugs and issues.

Here's a rough list of what is new from last week:

• Moved/renamed a number of library files for better logical organization. Classes are now organized what they generally do instead of how they apply to a particular sample.

• Updated DbImage.ascx to better handle compound and GUID primary key tables. Also, page templates will disable AJAX partial rendering when editing an image column to allow the FileUpload control to work properly.

• Added support for complex where parameters. This can be seen in the pages under ComplexWhereParameters in the sample app that already have a Where clause for LinqDataSource but also use the filters to contribute extra components.

• Added automatic support for enumerated type columns. UIHint is no longer needed to reference Enumeration.ascx.

• Moved a number of extension/utility methods to the DynamicDataFutures class. This includes localization helpers, metadata helpers, and default value helpers.

• Consolidated IAutoFieldGenerator implementations into a single AdvancedFieldGenerator class. It now includes functionality enabling column ordering, programatically excluding a list of columns, and a workaround for issues with attribute localization.

• Refactored common LINQ Expression generation code into the LinqExpressionHelper class.

Update: I made a typo. This project is called Dynamic Data Futures, not Dynamic Data Features. Hope no confusion was caused by this. Please read more about it here.

6/25 Update: This sample has become part of the Dynamic Data Futures project on codeplex. You can still use this code but you should check out the Futures project as it contains a lot more. The key conecpts are the same, though some names or APIs might have changed.

Note: This post is part of a series, see the list of other Dynamic Data samples.

The FilterRepeater is a control in Dynamic Data that is responsible for automatically emitting a list of filter controls that can be used to filter data rows displayed for a table. The filters work by providing a list of where parameters to the data source for each supported column type. By default Dynamic Data supports foreign key and boolean columns and renders them using a DropDownList. This and upcoming posts will talk about ways in which you can add filtering for other column types and how to modify the filter UI.

All of the code referenced here is part of the AdvancedFilterRepeaterSample solution.To run the sample open the solution in Visual Studio 2008 SP1 Beta or later and run AdvancedFilterRepeaterSite (note: it might not be the default project for the solution, so right click on Default.aspx inside the project and choose View in Browser). Navigate to the list page for the Products table where you can experiment with some new filtering options. For example, type "con" into the Categories filter. You should see an AJAX autocomplete drop-down instead of the default drop-down list.

Introduction to FilterRepeater

FilterRepeater is a specialized Repeater control that will automatically bind to a collection of filterable columns for the given request's table: if a request comes in for /Products/List.aspx, it will bind to the columns in the Products table. The table is chosen based on the route that the request matched, or it can be overridden by setting the TableName and ContextTypeName properties.

To work correctly FilterRepeater expects its ItemTemplate to have correct content. Specifically, it requires a control with a known ID ("DynamicFilter" by default) that derives from FilterUserControlBase. When databinding occurs FilterRepeater initializes an instance of the filter control with information about the column to filter.

Below is a snippet of the code that ships in the default Dynamic Data templates:

<asp:FilterRepeater ID="FilterRepeater" runat="server">
    <ItemTemplate>
        <asp:Label runat="server" Text='<%# Eval("DisplayName") %>' />
        <asp:DynamicFilter runat="server" ID="DynamicFilter"
             OnSelectedIndexChanged="OnFilterSelectedIndexChanged" />
    </ItemTemplate>
    <FooterTemplate><br /><br /></FooterTemplate>
</asp:FilterRepeater> 

FilterRepeater version 2.0 (well, more like 1.1 really)

The DynamicDataExtensions project contains a simple extension of FilterRepeater called AdvancedFilterRepeater. It is not really that advanced (I started with that name and never bothered to change it) as it overrides only one method: GetFilteredColumns. This method is what is used as the databinding source. Below is a slightly simplified source of how it is implemented:

public class AdvancedFilterRepeater : FilterRepeater {
    protected override IEnumerable<MetaColumn> GetFilteredColumns() {
        return Table.Columns.Where(c => IsFilterableColumn(c)).OrderBy(column => column, new FilterOrderComparer());
    }

    protected bool IsFilterableColumn(MetaColumn column) {
        if (column.IsCustomProperty) return false;

        var filterAttribute = column.Attributes.OfType<FilterAttribute>().FirstOrDefault();
        if (filterAttribute != null) return filterAttribute.Enabled;

        if (column is MetaForeignKeyColumn) return true;

        if (column.ColumnType == typeof(bool)) return true;

        return false;
    }

    private class FilterOrderComparer : IComparer<MetaColumn> {
        // implementation omitted for brevity
    }
}

The Table property is automatically populated with the right MetaTable instance based on the table resolution rules mentioned in the previous section. The rest is a simple LINQ extension method query and some boolean logic to choose the filterable columns. The only way this deviates from the default process is the addition and handling of FilterAttribute, which is a new attribute written for the purpose of this sample. It combines the roles of UIHintAttribute and ScaffoldColumnAttribute from Dynamic Data field templates and should be applied to columns in an analogous manner. Here's the full signature:

public sealed class FilterAttribute : Attribute {
    public string FilterControl { get; set; }
    public int Order { get; set; }
    public bool Enabled { get; set; }
}

The FilterControl property lets you specify which user control to use as the filter while the Enabled property lets you omit a given column's filter in the AdvancedFilterRepeater. The Order property let's you specify an ordering weight.

Specifying custom filter controls

The reason why the implementation of AdvancedFilterRepeater is so simple is because a lot of work is done in two other components:

• FilterFactory is the equivalent of FieldTemplateFactory for filters. It uses the information in a column's FilterAttribute to determine which filter user control to instantiate for the column. It takes the value of the attribute's FilterControl property and looks for a user control located at ~\DynamicData\Filters\{FilterControl}.ascx. If a filter attribute is not specified ~\DynamicData\Filters\Default.ascx is used, which is identical to the FilterUserControl.ascx that is part of the default Dynamic Data template.
• DelegatingFilter is a control that derives from FilterUserControlBase (which means that it is itself a filter) and delegates the filtering behavior to another filter control. It uses the FilterFactory class to determine which control to use.

In order to take advantage of AdvancedFilterRepeater and DelegatingFilter you need to replace the existing FilterRepeater in your List.aspx page template with the following code:

<asp:AdvancedFilterRepeater id="AdvancedFilterRepeater" runat="server">
    <HeaderTemplate>
        <table>
    </HeaderTemplate>
    <ItemTemplate>
        <tr>
            <td valign="top"><%# Eval("DisplayName") %>:</td> 
            <td><asp:DelegatingFilter runat="server" ID="DynamicFilter"
                     OnSelectionChanged="OnFilterSelectionChanged" />
        </tr>
    </ItemTemplate>
    <FooterTemplate>
        </table>
    </FooterTemplate>
</asp:AdvancedFilterRepeater>

This template is pretty similar to the default one seen earlier in this post except it wraps each filtered column in a table row for cleaner formatting (yes, using tables for layout is wrong but this post is not about layouts). And of course DynamicFilter has been replaced with DelegatingFilter.

To take advantage of the custom filter controls included in the sample such as autocomplete filter or cascading filter you need to annotate your data model with FilterAttribute. Here's a snippet of how it is done in the sample:

[MetadataType(typeof(Product_MD))]
public partial class Product { }

public class Product_MD {
    // Display the Category and Supplier filters using the Autocomplete.ascx filter control
    [Filter(FilterControl = "Autocomplete")]
    public object Category { get; set; }
    [Filter(FilterControl = "Autocomplete")]
    public object Supplier { get; set; }

    // Display the Discontinued filter using the BooleanRadio.ascx filter control
    // Make sure the Discontinued filter is displayed first
    [Filter(FilterControl = "BooleanRadio", Order = 1)]
    public object Discontinued { get; set; }

    // Display the UnitsInStock filter using Integer.ascx filter control
    [Filter(FilterControl = "Integer")]
    public object UnitsInStock { get; set; }
}

When you run the application and view the list page for the Products table the appropriate filters get inserted automatically. Future posts will discuss how the more advanced filters are implemented.

6/25 Update: This sample has become part of the Dynamic Data Futures project on codeplex. You can still use this code but you should check out the Futures project as it contains a lot more. The key conecpts are the same, though some names or APIs might have changed.

Note: This post is part of a series, see the list of other Dynamic Data samples.

A while back I posted some sample code for adding custom metadata providers. Since then much has changed in the Dynamic Data runtime and it is time to post an updated version. This sample illustrates how to write a custom metadata provider that allows you to programmatically add metadata attributes to an in-memory store before you register your model with the Dynamic Data runtime in Global.asax.

This sample should work with the latest preview release of Dynamic Data.

Running the sample

Download the metadata provider sample solution, extract to your preferred location, and open in Visual Studio 2008 SP1. The solution contains two projects: a sample website and a small library project that contains the metadata provider code.

Run the included website and go the Products list page. Once there hit Edit on any of the rows. You will be taken to a details view for the row you are editing. Change the UnitsInStock field to a negative value and move out of the field: a range validation error appears. Go back to the same field, clear it, and move out again: a required validation error appears.

How it works

The website scaffolds a small subset of the Northwind sample database. The UnitsInStock column on the Product table is decorated with two attributes: RequiredAttribute and RangeAttribute. However, the unique thing here is that each attribute is coming from a different source.

The RequiredAttribute is declared in the default Dynamic Data way using a metadata proxy class:

[MetadataType(typeof(Product_MD))]
public partial class Product {

    private class Product_MD {
        [Required(ErrorMessage="This field is required [from MetadataType]")]
        public object UnitsInStock { get; set; }
    }
}

The RangeAttribute is added to the InMemoryMetadataManager class in Global.asax:

InMemoryMetadataManager.AddColumnAttributes<Product>(p => p.UnitsInStock,
    new RangeAttribute(0, 1000) { 
        ErrorMessage = "This field must be between {1} and {2} [from InMemeroyMetadataManager]." }
);

The AddColumnAttributes function shown here has a way to strongly type the property references (as opposed to writing something like AddColumnAttributes("UnitsInStock", ...)) using a simple lambda expression. This provides for some nice IntelliSense support that would not be available if you were referring to properties using simple strings.

In order to have the Dynamic Data runtime pick up the metadata attributes added to InMemoryMetadataManager you need to modify your model registration call in Global.asax:

model.RegisterContext(typeof(NorthwindDataContext), new ContextConfiguration() {
    ScaffoldAllTables = true,
    MetadataProviderFactory =
        (type => new InMemoryMetadataTypeDescriptionProvider(type, new AssociatedMetadataTypeTypeDescriptionProvider(type)))
});

The MetadataProviderFactory property of ContextConfiguration lets you specify a metadata provider factory method that is used by the Dynamic Data runtime to obtain an instance of a TypeDescriptionProvider that acts as the source of metadata attributes for a given table (type). The sample above also illustrates TypeDescriptionProvider chaining, which is what supports the fact that the table receives metadata from two sources: the InMemory provider adds its metadata to the results returned by the AssociatedMetadataType provider and returns a combined collection.

Truly dynamic metadata

At this point it is tempting to consider a dynamic metadata provider that would let you add, remove, and modify attributes throughout the lifetime of the application and not just during the application's startup phase. For example, you could imagine having some sort of administrative interface that would let you turn on and off whether a field is required or modify its description, even after the model has already been registered.

While it would seem that such a scenario would require minimal changes to the InMemoryMetadataManager class there is one detail about Dynamic Data that makes this a lot more complicated: the current Dynamic Data runtime fetches the metadata upon model registration and then caches it inernally for the lifetime of the app domain. This means that any changes that you make to the metadata through InMemoryMetadataManager after the model has been registered will be ignored.

This is a limitation of Dynamic Data that we will address in future versions. For the time being the only way to get around this would be to unload the app domain. However, this is means that you will need to find a place (such as a database) to store the new metadata while the app restarts.

What about the XML metadata?

My old custom metadata provider sample had an implementation of an XML-based metadata provider but the current one does not. The reason for this is that since the December CTP we have added support for even more attributes and some of the attributes have become a lot more complex. Because much of the old sample had to do with deserializing CLR attributes from an XML representation instead of anything specific to Dynamic Data I decided not to develop the old XML provider any further. However, if somebody ever wrote the appropriate XML parsing code it could easily be used to populate the InMemoryMetadataManager with the right values, essentially resulting in an XML metadata provider. Just remember about the domain unloading mentioned earlier.

In breaks between writing the Dynamic Data runtime I also write samples illustrating the various ways Dynamic Data can be extended and customized, often in response to questions on the Dynamic Data forum. In a series of upcoming posts I will share these samples with you as well as discuss how the various extensions work with the Dynamic Data runtime. This post is meant to serve as a list of the samples:

• Custom metadata providers
• Extending the FilterRepeater {5/29 new}
• Autocomplete filter
• Cascading drop-down filter
• Declaring filter ordering
• ....

The list will be updated with links as samples become available.

We have posted the latest Dynamic Data Preview bits to Code Gallery. You can get them here. Note that you will need Visual Studio 2008 SP1 Beta and/or .NET Framework SP1 Beta installed to run everything.

See this ASP.NET forum post about what has changed.

In other news, I will soon be posting a collection of samples that illustrate a number of extension hooks. Stay tuned ...

One of the new things we are working on in ASP.NET is not directly connected to the new and improved features but rather to how we deliver them. Instead of packing all the functionality into binaries and DLLs, Dynamic Data "implements" a lot of what it provides in project templates. This is a pretty novel concept for ASP.NET with unique challenges yet some very exciting possibilities. Want to know more? Well, read on...

Your everyday basic project template

Most project templates you find in a default installation of Visual Studio (at least under the Web category) are very immature, little things. I do not mean to say they are useless. They certainly have a lot of potential... but you have to nurture them until they can develop into strong, functional applications, web sites, and utilities. Without any encouragement they pretty much do nothing. So I guess they might be a bit useless. Have a look here to the left.

There is nothing more here than a simple web.config file and a blank WebForm. Not even a friendly "Hello world". Instead, when you run this site all you see is a clean, white page. Essentially, this is an altricial creature in the Project kingdom.  Now, if you wanted this baby beast to do something - like... oh, I don't know... display and edit some data - you would have to: add database connections, create data models, drop in controls, specify tables, choose columns, enable flags, hook up events. And you would have to do all this for each table of data you are interested in. Quite a lot of work, if you ask me. And things get even more complicated if you want to add fully-editable and filterable relationships and other goodies.

A beefed up template

So we decided to make things a lot easier. And that is how, quite precocially, ASP.Net Dynamic Data was born. If you want to see how quickly you can get a working site running, see this excellent screencast by David Ebbo.

The idea behind Dynamic Data is to get you up and running with a fully usable app in minutes. To achieve this goal, however, we had to depart from the tradition of providing only the simplest application skeleton.

Observe to your right: this fine specimen is the default Dynamic Data project template that shipped as part of the December 2007 ASP.NET 3.5 Extensions Preview. All of these files (and a few more under the collapsed Images folder) are what you get when you create a new Dynamic Data project. While the exact composition of this template has changed significantly over the last few months (e.g. the folder structure is different, we favor Global.asax instead of web.config, and all the files are code-behind based), this is still a very good example of everything that you get by default:

• web.config
• Default.aspx - except this one actually does stuff
• a number of page templates
• a master page to make sure it all looks the same
• a bunch of user controls
• some styles
• a few images

That is basically the trick - you get half or even more of a fully functional application for free thanks to the Dynamic Data engine and the project templates. And since the functionality is divided between different files, you can easily customize and replace pieces as you see fit.

How do we nurture these templates?

All of this comes at a price, however... at least to us - the Dynamic Data team. One of the reasons why the majority of the default project templates is so small might very well be because it is a lot easier to support them (that and the fact that it is hard to come up with anything more complicated that would make a meaningful default). The smaller the code the less you need to worry about breaking it.

In the case of Dynamic Data the situation is further complicated due to the number of various combinations we want to support:

• C# vs Visual Basic
• Web Sites vs WAPs
• Linq To SQL vs Entity Framework
• Inline vs Code-behind

In order to avoid having... let's see... 1, 2, 3... 16 different project templates and lots of redundancy we have a pretty neat solution that combines templates, token replacement, automatic language translation, file stitching, and a few other steps to produce the end result from the absolute minimum number of source files. And in the rare few cases where our automatic tools are not sufficient to account for the differences between the various technologies we use or support, we just have manually written overrides.

On the positive side, this means that a large part of the functionality is not locked away in some impenetrable, sealed DLL. If you do not like how something works, you can quite easily replace it. And if by some remote chance there is a pretty nasty bug in the Dynamic Data CTP code (which there was), your chances of a workaround are just a bit better.

If you still have not checked Dynamic Data out, give it a go. You might just get done with your next project that much quicker.

Users of our recently released December preview of the new Dynamic Data feature in ASP.NET have noticed a pretty serious bug relating to foreign key column drop-downs. While this could be a breaking issue for many trying to test or adopt the new feature, I am glad to report that there is a workaround available.

This post talks about what the bug is and what steps are needed to resolve it. I am also attaching a zip file that you can simply unzip in the root of your Dynamic Data project (warning: this could overwrite customizations you have made to the project files. Read on to see what files are affected).

You can download the updated versions of the affected controls here (3 KB).

Bug symptoms

The bug affects the drop-down lists for foreign key relation columns as well foreign key filters. The problem occurs when you insert a new item into the parent table, then go to the child table and try to add a new entry, edit an existing one, or filter the table using the entry you added in the parent column. The drop-down list does not contain the newly added item and only restarting the entire app makes it appear (an analogous thing will happen if you remove an entry from the parent table).

This bug occurs because the Dynamic Data framework is trying to cache an instance of the DataContext object that represent the data model. The DataContext instance is something that should be instantiated, used to retrieve/submit information to the database, and then discard it. Dynamic Data holds on to it a bit longer than it should.

The solution

You can download the file mentioned at the beginning of this post to get the updated versions of the affected files. Simply unzip into the root of your Dynamic Data project. The included files are in C# but they should work even if your project is in VB.

The solution to the problem basically requires providing a new instance of the DataContext object to the controls responsible for rendering the drop-downs. This means you need to modify ForeignKey_Edit.ascx and FilterUserControl.ascx (both living in App_Shared\DynamicDataFields\ directory in the Dynamic Data project templates).

• ForeignKey_Edit.ascx

  In the Page_Load method, replace the following line of code

  DropDownList1.DataSource = parentTable.Query;
  

  with this

  DropDownList1.DataSource = parentTable.DataContextProperty.GetValue(Activator.CreateInstance(DynamicDatabase.TheDatabase.CreateDataContext().GetType()), null);

• FilterUserControl.ascx

  In the Page_Init method, replace the following line of code

  DropDownList1.DataSource = DataSource;

  with this

  var foreignKeyColumn = DynamicDatabase.TheDatabase.GetMetaTable(this.TableName).FindColumn(this.DataField) as DynamicMetaForeignKeyMember;
  if (foreignKeyColumn != null) {
      // only kick in if we are dealing with a foreign key column
      DropDownList1.DataSource = foreignKeyColumn.ParentMetaTable.DataContextProperty.GetValue(Activator.CreateInstance(DynamicDatabase.TheDatabase.CreateDataContext().GetType()), null);
  }
  else {
      DropDownList1.DataSource = DataSource;
  }

The new code is a bit ugly but it should work. Upcoming versions of Dynamic Data will not have this problem.

David Ebbo has just posted a screencast covering the Dynamic Data feature in ASP.NET 3.5 Extensions Preview. It is 17 minutes long and covers the following topics:

• Creating a Dynamic Data project
• Creating a Linq to SQL model
• Running the scaffolded version of a Dynamic Data project
• Customizing data validation
• Customizing UI presentation
• Adding metadata to the model
• Writing custom pages in place of the scaffolded ones

Check out David's post.

5/22/08 Note: this post talks about an outdated ASP.NET release. Please have a look at this updated dynamic metadata provider sample.

One of the most powerful elements of the new ASP.NET Dynamic Data feature we are working on is the ability to associate metadata (for example, range validation or formatting) with your data model. You can then query the model and use the provided information to customize the processing of your data. In the recently released ASP.NET 3.5 Extensions Preview this annotation is done by declaring special metadata attributes on the partial classes representing the entities in the model. The initial implementation is a bit limited, however, because the metadata association can only be done using CLR attributes and those attributes have to be declared on the class (even if they pertain to the class's properties):

[Range("Quantity", 0, 10000)] 
[Range("Price", 0, 20000)] 
partial class Product { 
}

A better approach

The MVC Toolkit (which incorporates a number of modifications to the Preview that will be included in later milestones – download here) contains an alternative implementation. This implementation has the following improvements:

• A pluggable metadata model based on providers.
• New metadata attributes that can be declared on the properties of a special metadata "buddy" class.
• An alternative reference provider implementation based on XML files.

The best way to familiarize yourself with the new model is to look at the samples included with the MVC toolkit. However, here are a few points to get you started:

1. The registration of a metadata handler is done on a DataContext type using the MetadataHandlerRegistration class. This needs to be done only once per application, for example in the Global.asax file:

   protected void Application_Start(object sender, EventArgs e) {
       MetadataHandlerRegistration.Register(
           typeof(MyDataContext), 
           MetadataHandlerRegistration.XmlMetadataProvider);
   }

   Note: Only Linq to SQL models are supported in this version. Future releases will support both Linq to SQL and ADO.NET Entities.
2. MetadataHandlerRegistration contains references to 2 different metadata providers: buddy class-based and XML file-based.

Buddy class metadata

Buddy class metadata is a model in which you associate a "buddy class" with your actual data model class and declare the metadata attributes on properties of the buddy class. "Why do I need to declare a parallel class?", you ask. The simple answer is that the current versions of C# and VB have no concept of partial properties.

This implementation supports two ways of associating the buddy class:

1. Explicit: using an attribute on the model partial class that points to the type of the buddy class
2. Implicit: using a name matching pattern (append "_Metadata" to the name of the model class and look for a class with that new name in the current namespace/assembly)

Using the explicit option looks like this:

[MetadataClass(typeof(Product_Metadata))]
partial class Product {
}

public class Product_Metadata {
    [Range(0, 10000)]
    public int Quantity { get; set; }
}

Comment out the MetadataClass attribute and you get the implicit option.

XML file metadata

An alternative metadata provider uses an XML file as the metadata store. Currently the file location is hard-coded to be ~/metadata.xml. A very basic metadata.xml file could look like this (a slightly bigger one is included in the sample blog project of the MVC Toolkit):

<metadata xmlns="http://tempuri.org/metadataFile"
    xmlns:m="http://tempuri.org/metadataElements"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://tempuri.org/metadataFile ../Schemas/MetadataFile.xsd
                        http://tempuri.org/metadataElements ../Schemas/MetadataElements.xsd">
  <metadataAttributes>
    <metadataAttribute tagPrefix="m" assembly="MVCToolkit" namespace="Microsoft.Web.DynamicData.Metadata"/>
  </metadataAttributes>
  <tables>
    <table name="Product">
      <columns>
        <column name="Quantity">
          <m:Range Minimum="0" Maximum="100000"/>
        </column>
      </columns>
    </table>
  </tables>
</metadata>

The metadataAttributes section defines metadata attribute mappings. These are used by the logic that creates a CLR attribute type instance from an XML element. For example, the m:Range element will be converted into the class Microsoft.Web.DynamicData.Metadata.RangeAttribute in the MVCToolkit assembly. The attributes on the element are automatically converted and set on the properties of the attribute type instance. You can add your own metadata attribute collection by defining a new metadataAttribute entry.

The tables section allows you to define metadata on all of the tables and their columns that make up your model.

As a final note, most of the attributes on the root metadata element are there to support IntelliSense in your XML editor. The relative URLs work in the sample Dynamic Data MVC blog project. You might have to change some of the paths if you decide to move the XSD files around or if you create a new project in a different location.

Implementation details

The underlying implementation uses the TypeDescriptor mechanism from System.ComponentModel. It is basically a pluggable layer on top of standard reflection. Have a look at the code to learn more.

Conclusion

This post discusses elements that will be incorporated in some way or another in future releases of ASP.NET Extensions. However, some of the implementation details might change. We will certainly have detailed documentation for the final release.

In the meantime feel free to explore the provided code and make sure you give back any feedback you might have on how these features can be improved. You can post your comments/questions at:

ASP.NET 3.5 Extensions Preview discussion
ASP.NET Dynamic Data discussion

Additional resources

Visit these blogs for additional tips on ASP.NET 3.5 Extensions and Dynamic Data:

David Ebbo's ASP.NET blog
Scott Hunter: ASP.NET and .NET Musings

The ASP.NET 3.5 Extensions Preview is out. Get it here.

This includes:

• MVC
• Dynamic Data
• AJAX browser history
• Silverlight controls
• REST based data services

Hi everybody (and by everybody I mean the single person who accidentally stumbled upon these pages). My name is Marcin Dobosz and I am a developer on the ASP.NET team. I recently graduated from Duke University with a degree in Computer Science and for the last 3-4 months have been working on the new Dynamic Data feature of ASP.NET.

In this blog I will write about my work and whatever else strikes my fancy, Enjoy.