InsertWebsiteHere Progress

So it's been awhile since posting anything, and the main reason for this is that it's hard to explain some of the things going on in this system. However, now that I've got (most of) the hard parts done, I can give an overview of what's been put into this system and what's required to make it work.

The IWH DataSource Interface

First of all, the most important part of the IWH project is the IWH DataSource interface. The interface provides a list of standard functions that are used by IWH to modify its dynamic model. The default IWH DataSource (IWHDS) at this time wraps around PHP's PDO class. The methods contained in IWHDS perform the necessary translation (in this case, SQL queries) for altering and accessing the dynamic model. Below is a brief explanation of each table in the default schema:

• models: stores a list of different models that are stored by the database. This is a simple id => name assocation, with an extra field for a description.
• model_structure: stores a list of attributes for the stored models. This table is really the heart of the dynamic model system, as it defines attributes, types, default values, and order. Records in this table are linked to their respective model via model_id.
• structure_options: one feature in IWH that hasn't been present in any other dynamic systems I've created is the ability for attribute types to have custom options. For example, a timestamp field would be able to store an option specifying what format to use. These options are specific to their respective structure, so 2 timestamp fields would be able to use 2 different formats, depending on how they were set up.
• records: a list of records stored by the system. This table is primarily responsible for maintaining a list of all records, and stores only the type of model that the reference refers to.
• record_data: this table stores all of the information for the data models. It is easily the largest table in the system (in terms of number of records). Information is always stored as a TEXT type, as PHP provides the necessary facilities for converting to the proper type automatically. A TEXT type ensures that (almost) all types of data can be stored here. Fields in this table are tied to their parent record (record_id) and the type of attribute (structure_id). The attribute type determines how the stored data is presented to the user.

Combined with this database structure, a special programming interface needed to be developed in order to really leverage the dynamic nature of the system. The interface was designed to handle basic scaffolding automatically, with the ability for the programmer to override any defaults.

Super-Scaffolding and Attributes

In a traditional MVC system, scaffolding is commonly used to get a base system up and running. The scaffolding provides a form for input as well as the views necessary to present the data. Scaffolding in Wax/IWH is a much different process. Since the models may constantly be changing, the scaffolding is done automatically, but with a twist-- instead of writing custom views for each different MODEL, you write custom views for each different TYPE OF ATTRIBUTE. This greatly reduces the amount of code necessary to provide a working system, and allows a much higher level of code reuseability. Attribute types are stored in the attributes.wax block (within iwh.wax), and each one is made up of 4 basic parts (a context and 3 views):

• AttrnameAttrCtx: Each attribute has a corresponding context for doing any custom manipulation of data before sending the data to the user or the database. In the simplest sense, it acts as a controller. It contains these methods:
  • view(): Pass the data on to the view that will display the information. Any custom formatting (timestamp formats, for example), can be done here.
  • edit(): Pass the data on to the view that will present an input form to the user. This method is used both for adding and editing of data, so it should be coded accordingly. This method is usually pretty simple, as it must present data in a way that can be shown by standard HTML controls.
  • editor(): All attributes have the ability to store custom options. The example I've been referencing is if timestamps wanted to store a format. In that case, the editor() method might return a list of common formats used for displaying times, of which 1 could be chosen as the display format for this attribute.
• Each method in the AttrCtx has a corresponding view file which is embedded into the necessary forms via the AttrRenderCtx

And soon to come...

Users and ACL

So what's next? Obviously, a system like this isn't of very much use if anyone can edit the data or the data model, so one of the primary goals right now is the development of an integrated ACL and user system. This change will likely add another table or two to the schema, since ACL and User Control isn't the type of information that can be stored dynamically. The dynamic nature of the system will still be preserved, however, since dynamic models would be able to be linked to User accounts, allowing for the creation of profiles, favorites, etc.

RSS/ATOM/XML/and other Web 2.0 stuff

Additionally, getting data out of the system is just as important (maybe more important) than putting it there in the first place. As a result RSS/ATOM feeds will become an important part of future versions of this system. Using the ACL in conjunction with the dynamic models, the included RSS/ATOM feeds will allow for REST APIs to automatically be created for these data models.

Upcoming Poster Session

I hope to have most of these new features done by May 7th in time for the poster session. At this session, I plan to show off the features by upgrading (and in the process, rewriting) a helpdesk system for use by the Rensselaer Union System Administrators. If everything goes according to plan, it should be a pretty exciting demonstration.