property development

Related Articles
Silverlight 2 Release Candidate Now Available	26 September 2008
This evening we published the first public release candidate of Silverlight 2. There are still a small handful of bugs fixes that we plan to make before we finally ship. We are releasing today's build, though, so that developers can start to update their existing Silverlight Beta2 applications so that they'll work the day the final release ships, as well as to enable developers to report any last minute showstopper issues that we haven't found internally (please report any of these on the www.silverlight.net forums). Important: We are releasing only the Silverlight Developer Runtime edition (as well as the VS and Blend tools to support it) today, and are not releasing the regular end-user edition of Silverlight. This is because we want to give existing developers a short amount of time to update their applications to work with the final Silverlight 2 APIs before sites are allowed to go live with it. There are some breaking changes between Beta2 and this RC, and we want to make sure that existing sites can update to the final release quickly once the final release is out. As such, you can only use the RC for development right now - you can't go live with the new APIs until the final release is shipped (which will be soon though). You can download today's Silverlight Release Candidate and accompanying VS and Blend support for it here. Note that Expression Blend support for Silverlight 2 is now provided using Blend 2.0 SP1. You will need to install Blend 2.0 before applying the SP1 service pack that adds Silverlight 2 support. If you don't already have Blend 2.0 installed you can download a free trial of it here. Beta2->RC API Updates Today's release candidate includes a ton of bug fix and some significant performance optimization work. Today's release candidate also includes a number of final API tweaks designed to fix differences between Silverlight and the full .NET Framework. Most of these changes are relatively small (order of parameters, renames of methods/properties, movement of types across namespaces, etc) although there are a number of them. You can read this blog post and download this document to get a listing of the known API breaking changes made from the Beta2 release. We have updated the styles of the controls shipped with Silverlight, and have also modified some of the state groups and control template names they use. When upgrading from Beta2 you might find it useful to temporarily remove any custom style templates you've defined, and get your application functionality working using the RC first - and then after that works add back in the styles one style definition at a time to catch any rename/behavior change issues with them. If you find yourself stuck with an question/issue moving from Beta2 to the RC, please report it on the www.silverlight.net forums (Silverlight team members will be on there helping folks). If after a day or two you aren't getting an answer please send me email (scottgu@microsoft.com) and I can help or connect you with someone who knows the answer. New Controls Today's release candidate includes a bunch of feature additions and tweaks across Silverlight 2, as well as in the VS and Blend tools targeting it. In general you'll find a number of nice improvements across the controls, networking, data caching, layout, rendering, media stack, and other components and sub-systems. Over the next few months we will be releasing a lot of new Silverlight 2 controls (more details on these soon). Today's release candidate includes three new core controls - ComboBox, ProgressBar, and PasswordBox - that we are adding directly to the core Silverlight runtime download (which is still only 4.6MB in size, and only takes a few seconds to install): At runtime these controls by default look like: The ComboBox in Silverlight 2 supports standard DropDownList semantics. In addition to statically defining items like above, you can also use databinding with it. For example, we could define a "Person" class like below: And the add a ComboBox to a page like so: And then write the below code to databind a collection of Person objects to the ComboBox (by setting its ItemSource property): At runtime our simple app will then display the data-bound Person names (note that we set the DisplayMemberPath property on the ComboBox above to display the "Name" value from our Person objects): We could then implement a SelectionChanged event handler like below to run code when a person is selected from the ComboBox: Notice above how we can retrieve a reference to the selected "Person" object from the databound ComboBox using the ComboBox's "SelectedItem" property. We can then call the MessageBox.Show() helper method (new in the RC) to display a modal dialog box that displays some details about our selected person: New Control Skins The final release of Silverlight 2 will have a much more polished set of default control template skins than those that were in Beta1 and Beta2. Our goal with the default control templates is to have a look that is professional and attractive, can be used in the majority of applications as-is (without requiring you to author custom style templates), and which is also easily tweakable using Expression Blend. Today's RC build has skins that are close to the final look we plan to ship (there are a few final tweaks we are doing post RC on the focus color of controls, as well as to tighten up and tweak a few issues in some of the control templates). Below is the default look for the DataGrid, RadioButton, CheckBoxes, and the DatePicker controls with today's RC build: Note that the DatePicker control above allows users to type in a date (with a masked edit to ensure it is a valid date), or they can click the calendar icon to the right of the textbox and select the date using a popup Calendar control: One of the most powerful features of Silverlight and WPF, of course, is the ability for designers and developers to completely customize the look and feel of any control. This goes beyond simple styling of colors and fonts - you can literally completely change the visual UI of a control, as well as customize its behavior (for example: add animation) without writing any code. Within Expression Blend, simply right-click on any Silverlight control and choose the "Edit Control Parts" sub-menu to open and edit its control template: When in control template editing mode, you can manipulate any sub-element of a control (for example: a checkbox's inner content), as well as customize each "state" its in (notice the states pane circled in red below). This allows designers to customize what the control looks like in individual states (for example: checked, unchecked, mouseover, etc). Silverlight will then automatically handle animating the control from state to state depending on the user action: You can learn more about how Silverlight's Visual State Model works from my previous blog post here. Previous releases of Silverlight often rendered graphics on sub-pixel locations - which could cause lines and shapes to sometimes appear "fuzzy". The RC of Silverlight has a new features called "layout rounding" that causes the layout system to round the final measure of a control to an integer ("pixel snapping"), which results in crisper lines and fewer rendering artifacts. This feature is now on by default, and helps make applications look nicer. Summary The final release of Silverlight is not that far off now. It has been a pretty amazing project that has come a long way in a pretty short amount of time. If you have existing Beta2 applications, please start getting them ready for the final release - as once we release Silverlight 2, users that have existing beta releases installed will automatically be upgraded to use the final version. Testing your application out with the release candidate will ensure that you can easily update your applications and have them ready within hours of the final release. Let us know if you find issues with today's release candidate, and please make sure to post them on the forums on http://www.silverlight.net. Hope this helps, Scott

ASP.NET MVC Preview 5 and Form Posting Scenarios	02 September 2008
This past Thursday the ASP.NET MVC feature team published a new "Preview 5" release of the ASP.NET MVC framework. You can download the new release here. This "Preview 5" release works with both .NET 3.5 and the recently released .NET 3.5 SP1. It can also now be used with both Visual Studio 2008 as well as (the free) Visual Web Developer 2008 Express SP1 edition (which now supports both class library and web application projects). Preview 5 includes a bunch of new features and refinements (these build on the additions in "Preview 4"). You can read detailed "Preview 5" release notes that cover changes/additions here. In this blog post I'm going to cover one of the biggest areas of focus with this release: form posting scenarios. You can download a completed version of the application I'll build below here. Basic Form Post with a Web MVC Pattern Let's look at a simple form post scenario - adding a new product to a products database: The page above is returned when a user navigates to the "/Products/Create" URL in our application. The HTML form markup for this page looks like below: The markup above is standard HTML. We have two <input type="text"/> textboxes within a <form> element. We then have an HTML submit button at the bottom of the form. When pressed it will cause the form it is nested within to post the form inputs to the server. The form will post the contents to the URL indicated by its "action" attribute - in this case "/Products/Save". Using the previous "Preview 4" release of ASP.NET we might have implemented the above scenario using a ProductsController class like below that implements two action methods - "Create" and "Save": The "Create" action method above is responsible for returning an html view that displays our initial empty form. The "Save" action method then handles the scenario when the form is posted back to the server. The ASP.NET MVC framework automatically maps the "ProductName" and "UnitPrice" form post values to the method parameters on the Save method with the same names. The Save action then uses LINQ to SQL to create a new Product object, assigns its ProductName and UnitPrice values with the values posted by the end-user, and then attempts to save the new product in the database. If the product is successfully saved, the user is redirected to a "/ProductsAdded" URL that will display a success message. If there is an error we redisplay our "Create" html view again so that the user can fix the issue and retry. We could then implement a "Create" HTML view template like below that would work with the above ProductsController to generate the appropriate HTML. Note below that we are using the Html.TextBox helper methods to generate the <input type="text"/> elements for us (and automatically populate their value from the appropriate property in our Product model object that we passed to the view): Form Post Improvements with Preview 5 The above code works with the previous "Preview 4" release, and continues to work fine with "Preview 5". The "Preview 5" release, though, adds several additional features that will allow us to make this scenario even better. These new features include: The ability to publish a single action URL and dispatch it differently depending on the HTTP Verb Model Binders that allow rich parameter objects to be constructed from form input values and passed to action methods Helper methods that enable incoming form input values to be mapped to existing model object instances within action methods Improved support for handling input and validation errors (for example: automatically highlighting bad fields and preserving end-user entered form values when the form is redisplayed to the user) I'll use the remainder of this blog post to drill into each of these scenarios. [AcceptVerbs] and [ActionName] attributes In our sample above we implemented our product add scenario across two action methods: "Create" and "Save". One motivation for partitioning the implementation like this is that it makes our Controller code cleaner and easier to read. The downside to using two actions in this scenario, though, is that we end up publishing two URLs from our site: "/Products/Create" and "/Products/Save". This gets problematic in scenarios where we need to redisplay the HTML form because of an input error - since the URL of the redisplayed form in the error scenario will end up being "/Products/Save" instead of "/Products/Create" (because "Save" that was the URL the form was posted to). If an end-user adds this redisplayed page to their browser favorites, or copy/pastes the URL and emails it to a friend, they will end up saving the wrong URL - and will likely have an error when they try and access it later. Publishing two URLs can also cause problems with some search engines if your site is crawled and they attempt to automatically traverse your action attributes. One way to work around these issues is to publish a single "/Products/Create" URL, and then have different server logic depending on whether it is a GET or POST request. One common approach used to-do this with other web MVC frameworks is to simply hav