After getting my feet wet with xslt and learning its ins and outs I started building an xml file with the structure for our item-based data framework. Once completed I can infer the schema from it and generate a set of sql structures that reflect what is being stored in the xml. After that a simple web service can handle the data link and the entire thing can be stored in most databases without too much effort. Tie this into the .NET v2 web parts and other features for security and we'll be most of the way there. Here is the first run draft of the xml file I'm working on... Keep in mind it isn't complete and will probably change a bit:

 

After some discussion with manu, plans for NewGenesis are forming that will transform it into something somewhat different than previously envisioned. In the coming days there will be more information available about it. Feel free to send me a note if you're curious.

Yesterday I did a little more work on the Data layer of the framework. It compiles now (finally) though it is just entity type classes and a few related functions. I added some XML serializer code so that any type of object can be saved into an Item.  I have to work out some details with the ItemType class though. Also, I still haven't heard from many people about helping out. I get the feeling they're waiting for me to do it all for them.

As well as those basic types, Items in this new framework can be anything you like. Take files for example since I mentioned the file system was where I got the idea. A class called File could be derived from Item and expose custom properties that are just hooked up to the Attributes and Properties Dictionaries/Lists of the Item type. What needs to happen now is the plumbing to make this possible. I intend to add a few new functions to the Item type to Add/Update and Remove Properties and Attributes without having to manually do the checking if it exists in the dictionary and such. Then our custom properties just use the Item.AddProperty(name,value) function for example in its set and a simple Item.GetProperty(name) in its get. If anyone has a better way to do this, I'm all ears, but this seems the most logical to me at the moment.

Last week I pushed some updates to the database script and a base set of classes that require some attention. Many of the problems in the current Rainbow Portal project v1.5/beta will be cleared up by use of this back end. The first steps to the future will be DAL and business class layers that replace all data access methods for module developers. Since the framework will use Gentle.NET and iBatis.NET for data access, porting it to any of their supported databases should be trivial for those who know how.

 

The class layout is structured around the idea of an atomic unit of data called an Item. The idea for this was taken from the file system and will eventually have Permissions and ACL-like properties as well. To support versioning and publishing controls there are several built-in attributes on each Item that allow for this. Language support is added by the concept of Content Items. You see, each Item can be of any type derived from the base Item class, so you see something like this...

 

Site: a site/installation of the framework

 

Portal: a single portal inside a Site (for multi-domain and multi-portal installation support)

 

Page: a page in a Portal (pages have a separate tree structure to allow for navigation to be stored in the database separate from the pages themselves)

 

Module: a module/WebPart (microsoft copyright?) in a page

 

Content: this is what makes multi-culture easy.  Each Content Item can have a different language, version, etc...  This way a Module can easily share content with other Modules in an Item hierarchy (not to be confused with navigation) and can be syndicated in many different ways.

 

Now that I have laid out the basis for the framework, I need other developers to help me fill in the gaps and fix up the code for testing and production. This initial push shouldn't take very long to complete and will provide a sound base for the rest of the Module and portal developers to port their data storage to while we refine the framework further in the business layers.