Wednesday, August 29 - Qcodo and Beyond

I have had various one-on-one conversations with quite a few of you about this, but I figure a public post about this is long overdue, and it is about time to try and get some feedback from the larger community on this, overall.

How Far We have Come

For those of you who have followed the history of Qcodo, the CodeGen / ORM design and implementation is by far the most mature layer of the stack, which started back in late 2001. Second to this is the QForm/QControl architecture, and then finally the javascript and AJAX components on top of the QForm/QControl architecture. And of course throughout this period, parallel modules (e.g. QcodoQuery, Internationalization, Email and Web Services, etc.) have been added to the mix as well.

Analyzing the strengths and weaknesses of Qcodo (both in terms of the code/framework as well as the community/project), I feel that one of Qcodo's main strengths is its centralized, modular approach to web application development through consistent, predictable patterns.

For example, with CodeGen, all of your data objects and relationships work the same way.  With QControls, all of your widgets work the same way.  With the way core/customizable classes are laid out as well as with the way generated/customizable ORM classes are laid out, customizations from core or generated classes all work the same way.

Given the history of the evolution of Qcodo, unfortunately (but not too surprisingly) stability reflects maturity.  While I think everyone agrees that the CodeGen and core framework architecture is rock solid, people still do find bugs and issues with the more recent AJAX functionality, and things like QcodoQuery is still being added to on a regular basis.

Where We Are Now

But despite a few hiccups and even despite Qcodo's continued “Beta” status, with over 35,000 downloads nothing has prevented a whole host of companies, “Web 2.0” products, non-profit organizations, government agencies and consulting companies from building great applications using Qcodo.  I know the “Qcodo Showcase” page is long overdue (and it is still coming... I promise =), but just to name a few: AnchorFree, Barefoot Solutions, CaseySoftware LLC, Chess.com, Crowd Favorite Ltd, Data-Imagery LLC, Intrinsyx Technologies, Jabbits, LifeTango, Lockheed Martin, Media Net Link Inc., NASA, Podango, Progrexion Inc., Singles,com, Stanford University, Table XI LLC, TurtleFox, Uloop, and of course, Quasidea Development LLC.  And of course there are tons of other companies, products and organizations that I am forgetting at the moment.  (Please feel free to reply to this and let everyone know!)

However, looking at the landscape of toolkits and frameworks out there in the wide world of web development (slight pun intended), there are many tools out there that are on par with Qcodo, and there are many others that would even compete favorably against Qcodo.

Now, one of the things that keeps appearing in the feedback is the lack of sustained improvements of the framework over the past 2 1/2 years since it was initially open sourced.  There would be some periods of accelerated release cycles where improvements and bug fixes were put in very regularly, but then there would be some periods of stagnation as well.

And of course, the other common complaint is the lack of complete documentation.  While the examples site and even the API guide is a good start, you can always have and people will always need more, more and more.

Where We Might Be Going Next

With all this in mind, and given the evolution of Qcodo, and weighing Qcodo's unique strengths and current weaknesses against what's currently available in the market, I have started to see a lot of value in looking at how Qcodo might be able to integrate with other existing, stable toolkits and frameworks that are in wide use today.

Again, many people agree that Qcodo's strength is in its core engine, code generated ORM, and consistent modularized approach... and especially considering it's maturity and stability, there is no reason why any of these would change.

However, when you look at the world of JavaScript toolkits, Qcodo's JS solution does not necessarily offer anything that is significantly more unique or better than some of the other toolkits out there.  In fact, I think everyone will agree that some of the pure JS frameworks out there like YUI, Dojo and jQuery have quite a leg up against Qcodo.

Similarly, on the server side, when you consider some components like I18n, or even some unwritten functionality like PDF, centralized Search, or ServiceClient classes, the functinality in the well received Zend Framework has some significant advantages there, as well.

Over the past month I have spent more and more time looking at these various solutions, and I am hoping to get some feedback from the community on this:
** Is there value in having Qcodo's core start to integrate with some of these other toolkits where Qcodo's version of the functionality being offered is non-unique, below par, or even non-existent?
** Are there specific frameworks, or functionalities in some of these frameworks, that you feel are important to consider?
** With JS toolkits, specifically, is there a specific JS toolkit that you would recommend?  And if so, why?

Something to keep in mind: whatever the decision or decisions that we make on how we want to move forward in terms of integration, note that the following principles will always be in place:
** Qcodo's strength in its core engine and Code Generated ORM
** The consistency in Qcodo's approach to coding, design, and customization
** Adherence to all XHTML, CSS and JavaScript standards
** Solid Object Oriented Design

Therefore, “integration” from Qcodo's point of view will not be simply a library of files that get included with the core release.  But it really would be a much deeper level of integration.  This is the only way that Qcodo could continue to offer the consistency in approach that it has been over the past 2 1/2 years.

It would definitely helpful to hear people's feedback, especially with these last points in mind.  It's been a great 2 1/2 years thus far... here's hoping for many, many more.

I look forward to hearing what everyone has to say!

There are definitely areas where QCodo is lacking, but you hit on all the ones I can think of off the top of my head.

QCodo appeals to me as a framework where I know I'm free to go in and improve any area, without worrying about being encumbered by licensing restrictions, or bad coding practices. That, in my opinion is one of QCodo's core strengths, and the one that makes the codegen and form abilities so solid.

So in that respect, I share Francesco's concerns about perhaps loosing that control with the integration of other frameworks.

That said, I think there are guidelines we can follow that would allow us to choose other frameworks that still follow QCodo's standards for customizable and clean OO design.
1) All code must be under MIT compatible licenses. (This prevents us from being held hostage to another codebase's design changes.)
2) All code must be well documented (So it's easy for us to improve/use)
3) All code must follow strict OO design principles (again, to maintain QCodo's customization standards)

I think that any framework that meets those 3 criteria should be safe to integrate into QCodo, and if at some future point we don't like the direction their codebase is taking, we can fork off our own.

But apart from a resounding YES from me, I don't really have any current preference / knowledge of other libraries.

Take a look at QDrupal, a Drupal module that Mike Hostetler put together that I think does just what you want.

As a developer coming from other languages, and after spending quite some time going through other PHP frameworks, I can safely say QCodo fit my style perfectly.

I really am quite comfortable with what I can do quite easily by extending the codegen'd classes, and am amazed at how easily I can put complex systems together.

Having said that, I do miss the 'wow' factor of some of the JS widgets from other toolkits.  Dojo has amazing widgets that are slick, and really stand out from the crowd.

If there was a way to layer these widgets on top of what QCodo does well already, it would be the perfect solution for me.  Having a layered solution allows the QCodo community to focus on making QCodo excellent on the bottom layers, while the Dojo (or similar) community can focus on the UI layer.

Just my two-bits... I already love QCodo, but I can definitely see this improvement as being a big positive for its future.

As the head of a small web development company (<http://www.spinningclock.com>) I stumbled on Qcodo whilst reading PHP Architect about 6 months ago. At the time our development team was in the middle of evaluating various other frameworks and prototyping an in-house framework which revolved around code-generation.

The main framework which we evaluated was symfony (<http://www.symfony-project.com>). Whilst we found it to be enormously powerful and very well thought out, the learning curve to put enterprise level web applications together was simply too high for us at the time. Basically, we couldn't afford for each member of our development team to take a few weeks out to learn symfony.

This is where Qcodo really excelled. The main benefits over other frameworks we found were:

- Easy to learn - As long as you understand the principles behind OO and good database design then Qcodo is a natural extension of that. We were able to get up and prototyping in Qcodo within a week and ready for development in Qcodo within two (although the lack of documentation did prove to be a slight hinderance).
- No bloat - So many other frameworks try to do cater for everything and end up being full of stuff you don't need. Qcodo is exactly right in terms of functionality, all the building blocks for an application are there and nothing more!

Having used Qcodo to develop multiple live web apps, including a call centre management application which allows our client to make over 100,000 calls a day, we have found it to be a great asset.

That said there are definitely a few areas which could be improved upon which could potentially be resolved by integrating with another framework, these are:

Tight coupling of model, view and controller
------------------------------------------
You get one form per page which presents data from one data object which relates to one database table. In real world apps this is not necessarily the case. There are obviously ways which you can overcome this by writing custom code, however, imho code to do this should be in Qcodo by default.

This has been our main problem with developing on mature applications written in Qcodo, we've had to abstract much of the functionality out of the original code generated files which means we can no longer take advantage of the RAD techniques which Qcodo gave us during the initial implementation.

Documentation
-----------
Worth mentioning again, the examples are very good, but are not a substitute for good docs :).

Unit Testing
----------
Whilst I love the fact that testing is left up to us to determine how to do it, I think that Qcodo should at least make a nod to the fact that we need to test our apps by putting some skeleton files and documentation into the framework.

I definitely think that some of the above can be solved by taking the best bits / integrating with other frameworks, however, it should be done very carefully to avoid any excessive functionality which might confuse or otherwise muddy the water when it comes to understanding what Qcodo is all about - Rapid Application Development.