Interview: Mike Ho of QCodo

This is the second in a series of interviews we're making available to the CodeSnipers community. We have been working to track down people who we thought had something valuable to say about the software development community, tools, practices, or direction. Some of the names you will recognize immediately, others you've probably never heard of, but all of them have made an impact in one way or another. Without further delay... we have Mike Ho the lead developer of Qcodo.

Qcodo had its debut at the Zend/PHP Conference in October and few in our community were there. Can you tell us about how Qcodo came about and what it does?

Well at the risk of sounding like “yet another PHP framework”, Qcodo is in fact a PHP development framework.

It is focused on allowing development teams create good, solid prototypes in a ridiculously short amount of time, and for giving developers a toolset to mature these prototypes into full-fledge enterprise-level applications.

At its core, Qcodo is broken down into two main parts: the Code Generator and Qforms. The Code Generator focuses on analyzing your database to create basic Create, Restore, Update and Delete (CRUD) functionality. Qforms is an object-oriented stateful, event-driven architecture to handle web page and HTML forms processing, similar to .NET or Java Struts. Both obviously work with each other seamlessly. But you could definitely choose to just use one or just the other.

The entire framework originally started out over 4 years ago as just a simple but robust Microsoft SQL Server and ASP code generator while I was working as an independent contractor. Since then, it has been rearchitected and greatly improved upon throughout the years, first being ported to ASP.NET. Over a year ago it was redesigned specifically for PHP 5 and has been made into a full-fledged development framework for use with the many projects I have been fortunate enough to work on. Throughout Qcodo’s life it has been used on a wide variety of projects on all these platforms, from small startups to Fortune 500 companies like Covad and Lockheed Martin and large government agencies like Chicago Public Schools and NASA.

Earlier this year, I was fortunate enough to be invited to speak at the MySQL User’s Conference, where I talked about the code generator, specifically, and how code generation techniques could be used to greatly accelerate enterprise application development. The feedback was so overwhelming, not only for the technique, but for the code generator itself, that I realized that the market has a huge need for not just the code generator, but an entire framework like Qcodo to be open sourced. So I spent the next couple of months cleaning up the code and ensuring that it was clear of any proprietary or IP constraints, and released it as an open source framework in time for the Zend/PHP Conference.

Code Generation tools in the past have been great for putting the initial framework into place but often become relics once "real development" begins. Does Qcodo break this pattern?

Definitely. In fact, the most common reaction I get when I first talk about code generation with any development team is apprehension by developers who have seen the pitfalls of code generation on previous projects.

Qcodo tries to avoid those common pitfalls by encouraging development teams to incorporate the code generator an active part of the development process and by allowing developers the freedom to do infinite customizations on generated code.

The code generator uses database analysis in order to generate your basic CRUD functionality, as well as some other simple relationship- and query-based functionality based on obvious rules inferred from the database. For example, if you have a foreign key relationship between two tables, the code generator will go ahead and generate functionality to help a developer manage that relationship.

Whenever you make changes to the data model, the expectation is that you will use the code generator to re-generate your code. And in fact, it’s to a developer’s advantage to do so; suppose you add new fields, new tables or new database constraints. By regenerating your code, Qcodo will provide you the generated code that reflects those changes, so that you won’t have to.

But the best part of the generated code is that it’s also architected to allow for infinite flexibility. For every logical object that is generated, Qcodo will actually generate two physical classes. One is known as the “generated” class, and the other is known as the “custom” class. So for example, suppose you have a “person” table. Based off of information about “person”, Qcodo will generate a PersonGen and a Person class. The PersonGen contains all the CRUD-, relationship- and query-based functionality that Qcodo generates. The Person class is a subclass of PersonGen, and is basically a simple wrapper around PersonGen. The PersonGen will always be overwritten on subsequent code regenerations, but the Person class will never be overwritten. So as a developer, you can override and add any methods, properties, variables, etc., and place that code in the Person class. And whenever you make changes to the “person” table and regenerate, your modifications and customizations remain intact.

The concepts behind Qcodo seem similar to the Ruby on Rails framework. What are the major differences - or similarities - that you see?

Remember that Qcodo consists of two major parts: the Code Generator and Qforms.

Qforms provides functionality that is different than Ruby on Rails. There are frameworks out there which provide similar functionality to Qcodo’s Qforms, most notably ASP.NET, Java Struts, and PRADO. But Rails’s approach to the View layer is completely different than Qcodo’s.

In terms of the Code Generator vs. Object Relational Mapping, at the 50,000-foot level Qcodo’s Code Generator looks very similar to not just Ruby on Rails, but also all the other “ActiveRecord”-inspired frameworks, including Cake, Hibernate, NHibernate, and even the upcoming Zend PHP Framework.

Given a data model, all these frameworks provide you with an entire class library, complete with database access, relationship management, and attribute handling, which map directly to the tables in your database.

However, beneath the surface you will realize that Qcodo is very different from these other frameworks; the others focus on creating a class library using the metaprogramming technique of runtime reflection instead of code generation. In short, the functionality and properties of your object relational map is given to you through the use of runtime analysis (including database-structure analysis and class reflection). While some of these frameworks ease off on the performance hit of the runtime analysis through caching techniques, the principle is the more or less the same: given your data model with various tables, you create an empty class which extends a base/generic Object Relational Mapper class, which these frameworks usually call the ActiveRecord class.

By very nature of the fact that it your empty class is a subclass of this generic ActiveRecord class, the framework kicks in using database analysis and reflection to provide you the CRUD functionality for that database table. Note that these properties are never explicitly defined anywhere. You simply call on them in your new class, and the deep framework functionality within the ActiveRecord class performs the task.

Code Generation, which is what Qcodo does, takes an entirely different approach. The analysis is done at time of Code Generation, and produces an explicit set of class library code. So when your application runs through these classes, there is no runtime reflection or database analysis that is performed to provide the CRUD functionality, because all your CRUD functionality, relationship managers and attributes are already explicitly hard coded in your class libraries.

There are pros and cons to both approaches. For example, the future plan to have Qcodo generate Javascript code, as well, to support an AJAX Architecture (as I described above) simply cannot be done using ActiveRecord, as ActiveRecord doesn’t actually generate any code. It is probably a bit too low level to get into a full-fledged discussion on the differences in this interview, but on the Qcodo website in the Documentation section there is some information that weighs the pros and cons of each approach.

It appears that Qcodo Beta 2 will incorporate AJAX support. What sort of functionality will be in the core system?

Since its release, a lot of focus has been on Qcodo’s code generator. But many people don’t realize that the code generator is only half of what Qcodo is. Qforms, which is basically the “V” in MVC for Qcodo, is a very feature-rich HTML forms and webpage architecture that provides .NET- and Java Struts-like functionality to PHP.

As I mentioned before, it provides an object-oriented platform to have stateful, event-driven web forms. Any Qform you develop will have various Qform Controls, which can be HTML widgets like textboxes, listboxes, etc., but also more complex widgets like datagrids, calendar popups, etc. You can define controls on your web form and then define validation functions, display logic, etc., to be executed as server-side events on these controls. These server-side events can update various controls, add new ones, remove them, etc., and update the form’s view with its current state of user-inputted data. The functionality is so wide and deep that it would be too difficult to get into it for this article (although, there are quite a few documents on the website that can help a developer get started with Qforms, specifically).

But what is key to note is that all the event-driven logic for this is still written in PHP. So there’s no need to worry about writing things in Javascript and maintaining two code bases. And there is a central location on how HTML and client scripts are rendered, in case you need to make changes based on design constraints, browser incompatibilities, etc.

More specifically in terms of AJAX, I realized that projects and applications are looking to incorporate AJAX in one of two ways. One way is what people are calling the “AJAX Widget” approach. The best example of this would be Google Maps. Fundamentally, Google Maps is a basic page-based web application. AJAX is primarily just used in their main map image widget, which allows the user to scroll around within that widget, zooming in and out, clicking on thumbtacked locations, etc. Even though the AJAX widget is very cool, the application as a whole still depends on the request/response nature of web page-based applications. If you want to figure out driving directions, or if you want to look up another address, etc., it’s more or less a traditional HTML web form that’s making a full page request.

Qcodo Beta 2, which we hope to have out by the end of the year, will focus on adding this kind of functionality to Qforms. Qform controls will have the ability to not only define server-side actions, but also asynchronous server-side actions which would allow for controls to have updates by server-side actions taking advantage of the now-ubiquitous XmlHttpRequest object. Again, the key is that the logic you want called asynchronously is still just in written in PHP, which will greatly minimize code complexity.

The other way that some projects that are starting to use AJAX is to take web-based applications to another “level” of usability that almost perfectly mimics traditional desktop applications. Some people refer to this as the “AJAX Architecture” approach, and the best example of this would be Zimbra. Fundamentally, the architecture is no longer the response/request nature of individual web pages, but it is now a single large web page that gets loaded at application start, and a plethora of Javascript calls to load in modules, update/restore data from the database, bring up dialog boxes (both modal and non-modal), etc.

There is a Qcodo Beta 3 in the works (some time in early 2006) which will start to try and address those needs. At its core, we’re now no longer talking about a single code base in PHP. But we’re now talking about PHP being purely a control layer, with your entire view being in HTML and Javascript which would make direct calls to your PHP control layer. It can get pretty complex, but by utilizing the current framework, we can more or less easily generate an entire Javascript class library which will intrinsically know how to communicate with an entire PHP class library, which of course maps directly back to your database. These Javascript objects will mirror all the properties as well as the functionality/methods in its PHP object counterpart. And by still writing your business logic in PHP, the Javascript object can make asynchronous calls to the PHP object to perform even the most complex business functionality requirements.

What is the overall direction of Qcodo? What features and functionality do you see being incorporated into the 1.0 release?

Ultimately, the main push for the 1.0 release (which we’re hoping to have during Q1 2006) is to have a fully-stable framework that is production ready on enterprise-level systems. With this in mind we’re actively trying to ferret out and fix all the bugs as they come up. In terms of additional functionality, the only large piece of functionality we plan on adding is the support for AJAX I described above. There are also some smaller pieces of functionality that we hope to incorporate as well, including:
· Object-level caching
· Simple mechanism to allow for optimistic/pessimistic locking
· Support for object graphs
· Basic support for internationalization
· Object serialization/deserialization to XML
· SMTP E-mail handling
· RSS/ATOM handling

How many people are currently contributing to the core codebase? How would someone get involved?

There are quite a few people now contributing specific patches to the codebase, and an even larger number of people who are actively contributing bug reports, feature requests, and enhancement suggestions. The best way for people to get involved is to use the online forums on the Qcodo website to make these contributions. There are also instructions on Support page on the website on how to access the Qcodo CVS and to get the latest development snapshot.

Do you know which organizations - or types of organizations - are using or evaluating Qcodo right now?

There are numerous organizations that are using previous versions of the framework in production right now (and have been for the past 4 years). In terms of the open source version, based on feedback in the online forums there seem to be quite a few organizations that are starting to develop new applications and projects using Qcodo. This is in addition to a number of varied organizations that I am actively talking to and working with directly who are beginning project development with Qcodo. The types of organizations are just as various as they have been before, including a small strategy consulting company in Northern California, a large (100,000+ member) media outlet in China, and NASA, who I am in discussions with to see how the framework can be used by managers to help with research and development project management.

How can we get more information on Qcodo, documentation, and examples of working with it?
It’s all available on the Qcodo website, at In addition to documentation and some sample code, there are also two video demos that really highlight the power of Qcodo, and I encourage everyone to at least check them out. It should give most developers a starting point as to what they might be able to do with the framework.

As an aside, there are also some people working on a couple of Qcodo “Starter Kits”, which are full-fledged applications written in Qcodo, which give developers a learning tool to understand how the framework works and how it can be used to implement various types of functionality. It also gives developers a starting point to build other types of functionality based off of these Starter Kits. Look for those to be posted on the website soon.

Is there anything that you'd like the CodeSnipers community to know about yourself, your projects, or life in general that I've missed?

Nope – thanks for inviting me to share what’s going on with this nascent, although quickly growing and exciting framework!

About Mike Ho:When he’s not skiing in Lake Tahoe or playing cards with friends from church, Mike is working at Quasidea Development, an idea incubator. He has over 8 years of software development and IT consulting experience, with a client list that includes NASA, Microsoft and Lockheed Martin. He holds a B.A. in Computer Science from Northwestern University… Go Cats!