***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...

 

 

So I've had this desire to write my own rpg game that emulates one of the classis SNES rpgs - Zelda Link's Awakening, Chrono Trigger, Secret of Mana, Breath of Fire, FF3-6 (depending on which countries release you're referencing).



I started wrestling with organizing the classes I'll need, the method I'll use for storing and loading map details, graphics, and especially how I'll manage the active plane (what the user sees on the screen), as well as some sort of animation engine that will let me manage a larger volume of individual elements that appear to be moving.

My first step, after failing miserably at creating some basic character concept graphics of course, was/is to break the project into smaller peices and tackle its individual parts. I'm sure at some point I'll be able to create an ok looking character, it'll just take time. In the meantime, lets work on animating the character...or something simpler. What about a ball? I can draw a ball right?

I did some research and found that for my purposes using an older technology Sprites, I can effectively manage quasi-3d animations in a 2d plane. The idea behind Sprites is to take a larger image (what I'm calling a SpriteMap), and draw each frame for a shape for a single movement loop for each of it's directional movement patterns. I've created a SpriteEngline dll that allows me to regsiter sprites in a dictionary, specifying a Uri uri_spriteSource, double cellWidth, double cellHeight, int fps, enum AnimationDirection etc. which will allow a SpriteManager running a single DispatchTimer to interact with each Sprite, telling it how many frames per second to run the animation, which directional animation to animate, and if the animation should be animated in the first place.

I've almost got a test application running that will allow users to use their arrow keys to move a ball that will appear to be bouncing across the screen. In reality, a rectanglegeometry the same dimensions as a single frame on the ball's spritemap hides the rest of the image from the user, and what we are actually seeing is the entire spritemap's Canvas.Left/TopProperties being manipulated.



This being the first step in what will no doubt be a long journey, I'm thinking I'll develop environmental graphic elements next, keeping in mind of course that everything will need to be reusable. Templated trees, bushes, rock formations, and basic dirt/grass/sand/rock patterns for flat surfaces. I could very well be working at this in my off time for months if not years to come...but it's all in good fun =D