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

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.