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

Working Examples

So I got the basic parts of the framework done. By this I mean it's possible to create websites, but it's not necessarily pretty (or that easy-- yet). The code still needs some more restructuring and organization, but as this happens, the code footprint will be reduced and the functionality enhanced.


I've uploaded what code I have to the Google Code page at http://code.google.com/p/waxphp and have additionally uploaded the presentation given today. DCI is still an evolving concept, but with time, hopefully it gains support.

Wax Templating Engine

Like most frameworks, Wax makes use of a templating engine to make views easier to create. However, unlike other frameworks (like rails and CakePHP), Wax does not allow any embedded PHP code. Instead, Wax gives you the functionality to create new tags and interface directly with the view in the code. For example, if you had (in rails) a partial named _post.html.erb that rendered a single blog post, you would create a loop inside the view that rendered data from the model. Rather than trying to put logic like this in the view files, you could instead create a new tag. Within the view file, you would then put <Posts />. From the code, you register the tag name and it's corresponding class name (essentially a model). From this class, the data can be rendered in place of the Posts tag. Examples and more details are soon to come, since I still need to figure out a specific process for passing data like this. Update 7/30/09: Nevermind, I gave in to embedded PHP code.