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

CouchDB

I've been trying to figure out how to make MySQL or SQLite play nice with DCI, and there always seems to be some compromise when I design the interaction. In response to this, the default data storage method for Wax (besides SQLite) will be Apache's CouchDB.

CouchDB is a project started out of the need for a document-based database rather than a relational database. The bulk of web applications don't ever use most of the power of a relational database like MySQL or PostgreSQL, so why not use a data-storage solution that is more scalable outside of the application itself?

CouchDB uses HTTP to store/fetch data, using the 4 major HTTP request types: GET PUT POST and DELETE. The entire database is directly queried through HTTP, meaning that data can be requested directly from PHP or JavaScript, allowing for a more fluid interaction between the client and the data itself, and less need for requests back to the webserver.


CouchDB binaries are available for Mac OS X and Windows XP/Vista, and most package management systems for Linux have a CouchDB package.

DCI with REST APIs

DCI's extremely flexible runtime structure opens up several possibilities for RESTful routing. Since DCI uses a role-based runtime structure, we can use URLs to query the application as a dynamic source of data instead of a series of static links that provide access to the underlying system. This method allows for nearly transparent controllers, as explained below:

MVC REST Routing -- Standard Convention

Most MVC based frameworks, including Rails and Symfony, use a controller-centered routing model. For example, the default routes in rails translate to:

http://site.com/app/controller/
http://site.com/app/controller/action
http://site.com/app/controller/action/id

This routing method works for most web based applications but with DCI, there is no static routing to a controller, but rather a 'request for a dynamic context execution'.

DCI REST Routing -- Proposed Method

With DCI routing, there is a special consideration to take into account when designing a system. Since the runtime network is dynamically created, the same base actions can take place from completely different places with different actions.

For example, if we were creating a message board application, we could create a post from either a logged in context or an anonymous (application) context. The access URL would be different, but the same base action would be taking place with different 'arguments':

http://site.com/app/{context}/{data model}/{action}/{args}
http://site.com/app/app/post/create
http://site.com/app/user/username/post/create

In this situation, there are 2 distinctly different contexts executing the same action (create) on the same model (post). The app context is the public application context that is used to anonymously perform system actions. These actions could be reading an about page, submitting a form on the contact page, or they could be posting anonymously on a message board. The user/username context is used to perform system actions as a specific individual. This allows for models and views to be created, then simply deciding which contexts can perform which actions. In this way, we can mostly replace the job of the controller (providing model data to the views) with simple REST routing.


The source code is currently being reworked to reflect these capabilities.

Some Unique Framework Features

So up until now, DCI has really been the only distinguishing factor that separates wax from just about any other PHP framework. However, now that the base framework is in a useable state, I can begin work on the next steps: SaaS, project exporting and administration.

Wax was not designed as simply a web development framework, but as a SaaS framework as well. The goal is to allow multiple applications built off a single Wax installation. This is achieved by keeping all plugins/libraries and the like in the Wax installation rather than the application directory. In addition, there are no code generation tools (like in RoR), so you don't end up with multiple copies of very similar code.

With the SaaS mentality, we also want the ability to move apps to different servers. From my experience, when installing new web applications, the biggest problem is dependencies (especially in my experience with rails). Wax aims to solve this problem by allowing "project exporting". The goal of project exporting is to allow a project written with Wax to run on systems that might not necessarily have it installed. An application uses a designated set of blocks plus the base Wax core to run. Exporting allows these specific blocks and the core to be copied and reorganized in such a way that the application will run with its own (lighter) individual framework install. The way paths are resolved in Wax allows for all of this to happen without any changes to the application code.

Last but not least, with SaaS comes administration needs. Instead of having each application rebuild an administration interface from scratch, Wax will provide a central interface to administer all projects using a specific install of a framework. In addition, the administration will be set up in such a way that the administration pages for individual projects will all be located in this interface. Depending on a user's permissions, they may have access to administer all installed apps or just 1 or 2.

In addition to this administration area, the administration interface will provide a way to install/uninstall Wax blocks from the central SVN repository. This will allow for a centralized, easy way to deploy updates and dependencies, as well as a way to contribute user-created blocks. A command-based interface for automated usage will probably be designed off the same core libs once they are mature.

All this is future work (the administration and exporting will probably be a project for the fall), but I hope that it will accomplish my original goals for creating Wax:

• Centralized Administration and Configuration
• No need for the command line
• All the functionality of other frameworks
• A low learning curve
• Community centered package repository