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

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.

I Really Hate Rails. A Lot.

Why? Because it's not worth it. Over the past couple weeks I've been working on a project that uses Ruby on Rails, trying to develop a plugin for it. It has been an absolute nightmare.




First I tried installing Rails on Windows. Ruby is a language that makes very heavy use of the command line and command line tools. As you may have guessed, Windows doesn't play well with that. Getting Ruby running is easy enough, but anything past that becomes tedious. Here was my experience.


I needed to work on a project that resides in a git repository, which is where the trouble started. Getting git to work on Windows took awhile, but I managed to get it up without too much trouble, so I continued on. I downloaded the Ruby One-Click Installer, ran it, and was happy to see everything was working fine -- or so I thought.


Next I had to install the Rails gem-- which should be easy enough, but no matter what I try, the gem command always says I need to update to a different version of RubyGems (even though it's the latest version). Eventually I managed to fix that somehow (no idea how). Second, the project I'm working on specifically requires Rails 2.2 -- not a big deal, just add -v=2.2 to the install command. Well, I lost some time here just because Windows wants the entire "-v=2.2", not just -v="2.2" string to be wrapped in quotes, or it will completely fail.


So I finally get the right versions of everything installed and I'm ready to get a running copy of this application. I try starting the server (ruby script/server) and get the message that I need to migrate the database. Easy enough -- just a simple rake db:migrate command right? Wrong. The rake failed because I needed to run rake create_a_secret. Fine. So I run rake create_a_secret, which fails because the command apparently makes use of some commands that don't exist on Windows machines. At this point I'm extremely frustrated.



Trying it on Mac:

So most Rails users use Macs, so I figured I'd try getting this all set up there. I retrace the steps I took on Windows and was surprised to find that it was relatively painless. I got the base application up and running, so I decided to create a new project so I could actually start learning Rails. Everything seems to be working fine, until I want to start creating relationships. Turns out sqlite produces all sorts of errors when using the belongs_to, has_many, etc functions. Well, I already had MySQL installed for the application I was working on so I figured I'd just change the configuration to use MySQL instead. Well that failed too. Turns out to make everything work I'd have to download the MySQL source code, the mysql gem source code, compile them against each other and do all sorts of other stuff just to make this application connect to MySQL. Not worth it.



By this point I've spent so much time trying to get Rails up and running that I'm ready to throw my laptop across the room. For all the work it takes to get a working rails environment, I just don't think it's worth it to choose it as platform for development. The reason I got into web development is because the technologies are cross-platform and applications can be delivered to any system. On top of that, you don't need much to create a web site, just a text editor and a server. Ruby has so many dependencies, requirements, and quirks that it causes more problems than it solves. The syntax is very implicit, making it difficult to follow for beginners.



These are some of the reasons I chose to start this project. I wanted a framework that didn't require a single bit of command-line interaction (no I don't have anything against the command line-- but it's a system tool, not a web development tool), that could be used from any machine, and that didn't NEED to be installed, just loaded (require_once('wax_init.php');).

Ruby on Rails

Recently I've agreed to work on the Crabgrass and SocialGeo projects. With these projects come a few technologies that I'm relatively inexperienced with, including Ruby on Rails and a Java-based map server. I've taken the time to learn Ruby and get acquainted with basic rails functionality. I've also looked around the Crabgrass code in an effort to understand the Rails development process a little better. With this new experience, I'm able to resolve a few roadblocks that I've had in my own framework development. Many of these developments are in the area of TemplatedControls, as Rails has demonstrated a nice development process for passing model data to the views. Some of my time from now on will be dedicated to these other projects, but I hope to keep progress strong on this project as well. Hopefully working with these other technologies will provide some insight into how I can make improvements.