***Update 03.12.10

I've gone ahead and implemented a majority of the below in a solution with the exception of a few differences. I've created a custom syntax (Dictionary<string, string> pmodifier - <propertyname, rendercode>) that equates to how I want each property to render in Xaml and attached this to my property. The interface has an option to BuildFromObject(Object object) and iterating the object we create a grid with rows/columns/controls/dependancy properties setup on the fly. The interface (Grid) itself has the actual object bound to it with Mode set to TwoWay, and each object added for each property is bound to the property itself. When you make a change to the say TextBlock.Text representing the Object.Name, you're actually updating the object. In this way, if you call a function e.g. UpdateObject passing the DataContext object, you've got your updated properties for use.

I've not quite worked out Validation, but I'm thinking I'll setup a few basic Converters that use regular expressions for string length, integer value, as well as a common set of regex's for phone numbers, addresses, etc. It is pretty cool to see the app working though - All I had to do to create an edit interface for a number of different objects I hadn't even looked at was load them in and bam, my interface was created for me. I'm looking forward to the moment where say an object needs to be updated, say a Customer object needs another field that holds a secondary contact or boolean field. I'll just add the new field to the object, update the pmodifier dictionary for the object and that will be it.

***

I was in the middle of designing a CMS tool (using Silverlight/C#) this evening while I came across a series of thoughts that I just had to write down somewhere.

CMS (Content Management System) - the CMS that I'm designing needs to be able to allow users to add/edit/delete/modify access for a number of object inehrit to the application. Pretty standard stuff - however, what happens when users want to create their own custom objects, or perhaps code changes and objects are modified? Hardcoded interfaces and functions may or may not support these changes.

Here's where things get interest. Since our objects are stored in a database with properties and access information, why not create a CMS that builds the edit interface on the fly, reflecting any changes made to the individual object? How is this possible? Databinding and a few helper classes - when the CMS loads, we pull a query for unique object types in our objects database. For each unique type we can construct a menu that iterates a list of standard operations (Add, Edit, Delete, Access, etc.) Our CMS will contain a wizard control that will manage our steps for each standard operation. Our primary step for any object will be selecting an object, so a simple query for objects of the specified type will suffice. Subsequent steps will require diffrent interface, action dependant.

For the purpose of example, lets look at editing an object. The user selects edit under the menu for a type of object - a combobox say loads with all objects of that type. The user selects an object, the wizard control then knows for any edit action to build an interface that allows the modification for all preperties of the selected object type. A helper class will be needed of course to intercept the property object type and return a control that matches it (e.g. typeof(bool) will return a checkbox while typeof(string) will return a TextBox and any derived collection type might return a combobox or listbox). These controls when returned will be databound to the property name, while the wizard layoutroot (or whatever parent FrameworkElement will have it's DataContext bound to the object itself with Mode set to TwoWay. While it will be harder to actually control the layout of the wizard's interface, basic layout can easily be implemented by calculating the number of various control types (equating a style derived dimension for each (and attaching said style)), getting your wizard control dimensions and setting your view parent uielement to a grid, generating an adequate number of columns/rows and alternating between columns and rows while adding each interface element.

To actually perform your database update, web services can be setup take an inherited base object type that identifies the object type passed and pushes updates to the appropriate tables using Linq to SQL, stored procedures, or whatever your prefferred method is.

This seems like a pretty cool setup as if object properties change or perhaps individual objects require different properites or perhaps you have a set of completely user specific objects, creating and managing a CMS tool can be pretty easily implemented without developing numerous interfaces or custom logic.

You might ask, what about validation? Silverlight 3 introduced some pretty cool validation support that allows objects to validated at the property level or even CustomValidation for validation of single entities at once. This does complicate our runtime generated UI by dissallowing custom validation and only allowing for basic validation (i.e. is a number or is length > 0 or is not null), but you could perhaps create another validation object with properties that represents custom validation rules with an object type to validate link and build your custom validation from this model.

Just a few thoughts...