Wax PHP Framework

Zoho Creator

2010-05-05T16:50:00.004-04:00

So I found a company that provides basically the exact same functionality that I hope to provide with Wax. I knew there had to be someone out there with similar ideas, I just can't believe it took this long to find them. The company is called Zoho and their product is called Zoho Creator. It's basically designed to be an online database builder that lets you build custom applications around the database. So, if you want to see the long term aspirations for this project, check out http://www.zoho.com/creator/platform-features.html

Wax 0.11 and a Tutorial

2010-05-05T00:35:00.008-04:00

So I finally managed to get a release together in time for this poster session. There are some things that I had hoped to have working that I just didn't have time for. The greatest contributor to this is that I did a rewrite on most of the blocks used by Wax after changing the routing methods.

Features Supported, but are probably still pretty buggy

Scaffolding (Create/Read/Update/Delete)
Dynamic Model (Modify/Add Attribute/Remove Attribute/Remove Model)
- Fully implemented in DDS
- Partially Implemented by WaxPDO (implements the DDM directly in SQL using ALTER TABLE)-- NOT RECOMMENDED
Context wrappers (similar to controllers, but not really), and Role Methods
Views
Layouts
Wax Querystring Routing (/Object/_id/method/arg/arg/...)

Things that kindof work, but aren't documented and are full of bugs

See the previous post for more details about these.

Login System (Requires creation of extra views and custom session management code)
ACL (Front-ends aren't done, Still very buggy)

Things that don't work / not implemented / TODO

Ajax support
Recursive Models (IE: auto-detect parents and children when fetching data)
Advanced Attributes (facebook-style)
Hidden Attributes (for the AntiSpam attribute, mostly)
Custom Forms (more on this once it's implemented)
Multiple layouts/output formats (ie: HTML, Ajax, RSS, etc.)
CouchDB interactivity with the Dynamic Model *high priority*

Documentation is still pretty rough, but any feedback is welcome. There's also quite a few security flaws that I haven't quite sorted out yet. You can check out the tutorial at The Getting Started wiki page and grab the downloads from The Google Code Page or from the sidebar on the right.

Users, Permissions, and the ACL

2010-05-03T10:26:00.000-04:00

With frameworks inevitably comes the need to authenticate users and control permissions. In Wax, this need must be very carefully planned out, since the dynamic nature of the system allows for (almost) any object to have permissions on almost any other object. Let's consider a simple example: We have a Users object and a Tickets object. Regular users can view a list of tickets, while Administrators can CRUD the tickets. We want to make sure that these are the permissions applied in the system.

Creating a Model that has Permissions

As much as I would love to say that there is no coding involved in the creation of a login system, there are a few things that need to be done to make the system work properly.

Creating an Object with rLoginIdentifier and rPermissionHolder

The Wax DDM (Dynamic Data Model) provides two roles, rLoginIdentifier and rPermissionHolder which give regular old dumb objects the ability to act as smarter, permission having objects. First, an object must be created in the DDM. The object must contain a 'Username' field and a 'Password' field. Besides that you could store user information, last login information, etc., but 'Username' and 'Password' are all that are required. Secondly, the object must implement rLoginIdentifier and rPermissionHolder:

class Users extends DDM implements rLoginIdentifier, rPermissionHolder {}

That's pretty much it for the Login system

Implementing the rLoginIdentifier also gives the Users object the 'login' action, which actives the resource: /Users/login - which is the front-end to the login system. The Login system allows you to turn a regular dumb object into something useful with only 1 line of code (the Users class definition). Normally, the DDM handles all actions directed at a dynamic model, but in this case, we've overridden the basic DDM and given the Users object all of the dynamic functionality but added some additional functions as well.

Using the ACL

Using the ACL is just as simple as setting up a login system. In fact, half of setting up the login system is actually setting up the ACL. The rPermissionHolder role exposes 3 methods which interface with the Dynamic Data Model which allow for Getting/Setting permissions on resources.

Getting a User's Permissions

The User information is stored in the PHP $_SESSION object, which allows you to access the actual user information very easily ($_SESSION['User']). Using this information, an actual model can be instantiated:

$user = new Users($_SESSION['User']);

The permissions of any resource can then be checked with IsAllowed or GetPermissions.

if ($user->IsAllowed("SomeModel/modify")) {    
    // success
}
else {    
    // InvalidPermissionsException
}

$permissions = $user->GetPermissions();
/**
* Permissions would be something like:
* Array(
*    [SomeModel/] => 1,        // User has access to all function of SomeModel
*    [SomeModel/delete] => 0   // But there is also an explicit DENY to SomeModel/delete
* )
*/

By default, all permissions are denied for all users. Each ACL entry represents an ALLOW permission for some resource. As shown above, explicit DENYs can also exist, which is useful when you want to grant all permissions EXCEPT for some action-- in the above case, Deleting the objects is not allowed.

Login- A good example of customizing the dynamic model

2010-05-02T03:48:00.000-04:00

With the Dynamic Data Model rewritten in the new routing format, it was relatively easy to get the Login roles working. The next step is to make the ACL work. The login system is implemented in 3 different pieces:

The Users object
The rLoginIdentifier roles
The UsersLoginCtx context

Each of these pieces serves a different purpose, explained below.

The Users Object

The Users object contains the basic object that extends DDM. Additionally, it implements the rLoginIdentifier which provides the Authenticate() and session management methods. This object also provides the target for the actual request-- as in the URL for accessing the login function is:

/Users/login

rLoginIdentifier

The rLoginIdentifier role provides methods that Authenticate the user against the dynamic model. It makes use of the PasswordAttribute class and the rPasswordHasher role to hash the password using a User-specified hash function. The LoginIdentifier role also provides access to 2 session management methods:

SetSession($var, $value)
DestroySession()

Where SetSession can set and unset session variables, while DestroySession can destroy a session for logout purposes.

UsersLoginCtx

This is the class that actually handles the Login request. Requests are handled either by a corresponding context name (ie: UsersLoginCtx) or role method (Users->Login). In this case, the context is used since each application's Login method will be different and as such, should not be coded as a role method. Since the Authenticate role only returns the result of the actual Authentication, this context is responsible for handling the result of the Authenticate function. It takes the result and stores it in the session, then redirects the User to the home page. This context must be coded specifically for each application. It allows for the basic Authentication module to be very dynamic (providing a list of different hash functions), while allowing the actual session management to be completely custom.

More To Come...

This is just this first example of the model of programming that Wax and the IWH package are built on. The roles will provide commonly used functionality (scaffolding, the dynamic data model, login/sessions, etc.), while the contexts provide a way to set up these function calls around custom application functionality.

MVC Got in the Way, So I Got Rid of It

2010-04-25T00:57:00.001-04:00

As development of this framework went on, I began to realize that I didn't need to use MVC anymore. In fact, I realized that the bulk of the work for the IWH project was simply working around MVC in order to get the system I wanted. One of these major challenges was adding special functionality while still maintaining the dynamic data model ideas.

Role methods to the rescue

Instead of analyzing a request to determine which controller should handle the request, the request provides a precise target of which code to run. For example, in MVC, this request would run the view method in the PostsController and fetch record #3:

/Posts/view/3

Instead of trying to figure out how Controllers fit into this new model, the routing method was rewritten, so the same request above would be rewritten as follows:

/Post/3/view

Which is analyzed into "I want to perform an action on a Post object. The object's id is 3, and i want to run the view method". Instead of routing this through a controller, we can instead give the Post object the ability to play the role of a ViewActionHandler:

class Post extends WaxObject implements rViewActionHandler

Which would link the Post object to the ViewActionHandler. Similarly, this concept can be applied to static pages as well:

/Home/mobile[/index]

Would tell Wax that the user wants to view the index() method on the Home object. This Home object's ID happens to be 'mobile'. We can use this identifier to link in different stylesheets, datasets, and anything else to distinguish the mobile view from the regular one.All in all, what does this mean? Well basically, it means that the word 'Controller' won't be found anywhere in the Wax source code because there aren't any controllers.

InsertWebsiteHere Progress

2010-04-21T19:31:00.000-04:00

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

2010-02-19T17:48:00.000-05:00

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

2010-02-10T17:35:00.001-05:00

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

2010-01-13T13:26:00.000-05:00

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

2009-12-02T03:03:00.000-05:00

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

2009-11-28T23:47:00.000-05:00

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

2009-11-14T17:08:00.000-05:00

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

2009-09-30T11:49:00.000-04:00

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

2009-09-27T13:37:00.000-04:00

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

2009-07-30T14:39:00.000-04:00

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

2009-07-17T13:56:00.000-04:00

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

2009-07-02T11:22:00.000-04:00

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.

2009-06-29T22:17:00.000-04:00

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

2009-05-27T03:10:00.001-04:00

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.

CSS Aggregation, Themeing, Entities

2009-05-25T20:54:00.000-04:00

Recently I fixed a few things that have been in the way of really creating functional websites. These included CSS Aggregation (required for dynamic themeing), Theme configuration files, and the ability to use common html entities from waxml files. CSS aggregation was a necessary feature because the aggregator would be responsible for applying the current theme colors and styles to other resources. With this functionality, controls can be designed to inherit information like color, border, and recommended padding size from the theme configuration file. An example of a theme configuration file can be seen here. Another irritating bug was the inability to use HTML entities like   and © within the waxml template files. This was due to the fact that these entities are not defined in the used XML schema. The workaround involved preprocessing the template files to replace common HTML entities with their ASCII counterparts. The XMLFixEntities function can be seen here, starting on line 20. Some reorganization of functions might be in order to separate the template loader from the Page object.

Code Page

2009-05-18T01:46:00.001-04:00

So I found out that searching for Wax PHP Framework yields results from a UK based company called One Black Bear. I'll be working on keeping the blog and code page active to try to raise up through the search results. In the meantime, the code page is located at http://code.google.com/p/waxphp.
Just as a side node - I couldn't find any actual information or code for this other framework.

Wax PHP Framework

2009-05-16T23:48:00.000-04:00

So now that the framework is starting to mature a little bit, I finally decided to create an actual blog so I don't have to just keep updating the project page on Google Code. Here's a brief summary of the work so far:

The project started off as WISP PHP Framework, meaning Websites with Integrated Scripts and PHP. The framework was designed to use PHP to generate an XML representation of a website and then use XSLT transforms and other manipulations to create a working website. As the project progressed, the development style changed and the goals of the project evolved. The current system uses XML template files as the base frame for the site, then uses PHP code-behinds to do any extra manipulation or logic. It uses a library of custom controls to piece together the application. If I had to relate it to any other language, it would be ASP.net.

Current features include:

XML based layout system
Custom control development
Custom control invokation via XML tags (ie: <CustomControl Attribute="Value">)
DOM based page rendering

Features temporarily broken during the rewrite include:

Integration with PHP PDO (PHP Data Objects)
Data sources and data binding

High-Priority features include:

Templated controls (Controls that can use XML as a base template, right now they must be all PHP)
Integration with SDO (Service Data Objects)
Script binding
Remote method invokation (calling PHP functions from JavaScript for use in AJAX apps)

Development will progress throughout the summer and will continue during the fall semester.

Anyone interested in helping with development or testing the framework can E-Mail me at joechrz@gmail.com or visit the Google Code page at: http://code.google.com/p/waxphp