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.

CoreDCI split into separate project

Wax's underlying DCI core has now been split into a separate library, called CoreDCI, and has been packaged as a way to provide DCI functionality in a more generic scope. Version 1.0 of CoreDCI was released today, and provides:

• DCIObject - allows for the creation of role-playing objects
• Context - a context class that is specifically designed for facilitating the execution of role methods
• DCIException - a custom exception class that provides a stacktrace that more accurately shows the DCI call stack
• The Account Example: a test file showing how to define roles, contexts, and model objects, then use the role methods to perform a Money Transfer operation. Also demonstrates the functionality of the DCIException.

The library is available for download at The CoreDCI project page.

InsertWebsiteHere Announcement

InsertWebsiteHere is a WaxBlock specifically designed for using Wax to build dynamic information systems. It provides everything required to get a simple, dynamic, and flexible system up and running in a matter of minutes. Here's a description taken from the Google Groups page:

The Idea: A large number of simple information systems start with the
request: "I need a website to keep track of my _something_". Let's
say in this example, the _something_ is books. Then, the "Book" model
needs to be created and defined (ie: Title, Author, Year, ISBN, etc.),
and the IS is based around the model. The issues arise when 6 months
later, the system user says "I also want to store the number of pages
in the book". Then the code has to be reworked (in several places) to
allow for this change, which can sometimes be an incredibly daunting
task. Wouldn't it be nice to have a system with a more dynamic data
model?

The Solution: InsertWebsiteHere uses concepts developed and refined in
the RPI off-campus housing system as well as several other systems
with a dynamic data model. The theory is that there is generally 1
primary data model and then all primary functionality is based around
that one model. In the case of the housing system, that model is an
apartment listing. In the book example, the model is a book.

More details and examples to come shortly. The release of the Wax AppKit 0.10 is also coming soon.


This project is made possible through the Rensselaer Center for Open-Source Software thanks to the generosity of Mr. Sean O'Sullivan.

Preparing for the poster session

In preparation for the poster session coming up in a few weeks, I've been spending some time fixing bugs and creating a useable (albeit anything from mature) data model library. In the future, I hope to wrap ActiveRecord around the DCI concept, but for the time being, a smaller, more specialized library has been developed.


The poster session content will focus mostly on the concepts behind the framework, the methods of implementation, and the advantages offered over standard MVC-based frameworks. In addition, I will explain the methodology behind the building-blocks application structure that I've shaped the framework around. Hopefully the poster session will encourage people to give the framework a try and help to make it a feasibly solution for real-world application development.


Code updates will be coming soon. Sometime in the near future, I will also be re-organizing the source repository to house the Wax Blocks in a different branch, rather than including them in the base framework. This is done in anticipation of the package management system that will eventually (hopefully in the next few months) be developed.

Application Kit 0.9.0 Released

The framework is finally useable. It's still missing many features that you'd expect in a framework and it's still pretty buggy, but for anyone adventurous, the Application Kit was released today. The Application Kit provides everything you need to get going with Wax. It provides a basic application structure that can be extended into a full application. The Application Kit is still only bundled with the 2 essential blocks: webcore and messageboxes. In the future, releases will be bundled with database connectivity blocks as well as some other utility blocks. Running the Application Kit is easy -- just unzip into the Document Root of the webserver and navigate to http://localhost/app.wax to launch the application. In the meantime, you can generate fairly static websites with the current version (0.9.0) of the Application kit, available at http://code.google.com/p/waxphp

Significant Changes & Code Update

Today I uploaded a fresh copy of the source code. This source is significantly different from the last commit and as a result many blocks were removed from the source. The framework SVN repository contains only the few base files needed for Wax to function properly. Some of the major changes are listed below:

Added include/ directory to block dirs

This change allows 3rd party libraries to be included with blocks. Previously, this was done through the blockname.wax/lib directory, however, this directory's purpose has changed.

Changed purpose of lib/

The lib/ folder now contains role-playing objects exposed to the rest of the runtime. Examples include Controllers, Models, and libraries.

Added blocks/ directory to block dirs

Blocks can now auto-include dependencies by putting them in the blocks/ subdirectory. This is especially useful for the new Application structure, explained below.

Applications are now simple blocks

Applications are now exactly the same as a regular Wax block, but with the addition of init.php and index.php-- the two files required to make a block executable. Applications can bundle their own dependencies and libraries using the new blocks/ subdirectory.

Added Exception Handling to the Core

Previously, Wax did not use Exceptions and used manual error catching. As the framework matured it was clear this wouldn't scale as easily as adding a global Exception handler. As a result, the WaxException class was added and the wax_exception_handler() and wax_error_handler() functions were added to core/include/exceptions.php Many roles were also rewritten to use Exception handling as opposed to simple manual error catching.

TypeHinting now Discouraged

Using TypeHinting in roles was encouraged up until now, when a significant conflict was discovered. When using the AddRole method after instantiation, the list of implemented interfaces is not modified. As a result, PHP doesn't know that the object now plays the new Role and the TypeHint will fail when calling a Role method. TypeHinting also is not the quickest feature in PHP, so its removal should result in a (very) slight performance gain. To replace TypeHinting, Exceptions are now thrown in the case of an Object/Role mismatch.

Close to a release

With the semester coming to an end and the framework maturing, I feel confident that by the end of the semester I'll have a working framework capable of creating simple websites. The initial release will require an installation of either CouchDB or MySQL for the database. Unfortunately, due to the vast difference between database systems, I can't guarantee the ability to switch between them once an application has been written. To put it simply, if you write an app using CouchDB, you'll have to restructure the entire application to make it work with MySQL. I'm currently looking into the reverse, which may be possible (Port MySQL to CouchDB).

Some of the basic blocks planned for inclusion are:

• webcore: responsible for MVC roles, default Wax theme
• couchdb: handles interaction with CouchDB
• mysql: handles interaction with MySQL
• msgbox: provides library for displaying different types of messages
• html: library for rendering different types of HTML controls, including forms
• form: extended library for handling forms, including file uploads