Almost two years ago I started thinking about rewriting the Lussumo Framework, the framework upon which Vanilla is built. After a year of heavy contemplation, I finally started development on the new version, which I have come to call “Garden”.
My concept for the Garden framework is not to be competition for the likes of The Zend Framework, CakePHP, or even CodeIgniter (to name a few of the other great PHP frameworks), but something both a little less and a little more. My idea was to create a framework that didn’t solve everyproblem, but just most of the common problems we face when developing simple web applications. I wanted to build a framework that had user and permission management built right in. I wanted to build a framework with which you could easily create new applications and throw them alongside any others – and all users, roles, permissions, preferences, plugins, and themes could play nice together.
Markosullivan.ca can safely say that I have accomplished that task.
Recently I had an active member of the Lussumo Community contact me and ask if his plugins for Vanilla 1 would work with Vanilla 2. It was hard to give him the answer that, no, none of the (over 400) plugins for Vanilla 1 would work with Vanilla 2. I had to explain to him that developing in Garden will be easier, faster, and take far less code than it used to. His questions made me realize that I need to step up and explain Garden to all of the great Lussumo Developers out there.
In this part of the Garden preview, I am going to give a brief overview of some of the main goals of Garden. In the parts to follow, I will go into great detail of each part of the framework, explaining the theories behind them and how they can be used by developers to build new applications, plugins and themes.
Extending Garden
In Vanilla 1 there were a number of ways that developers could add to the application. I called these Add-ons and they fell into the categories of: extensions, themes, styles, and languages.
When I started thinking about how to add to Garden, I realized that I was missing a key ingredient: applications. Vanilla is just one application, and I wanted to be able to use Garden to do more than just Vanilla. I also realized that almost no-one ever worked with themes (Hell, I started to do one and found it too difficult), so I’ve taken the concept of themes, simplified it and munged it together with styles. Finally, I realized that the lay-person doesn’t really know what an extension is, but everyone knows what a plugin is.
So, in Garden, add-ons will fall into the following categories: applications, plugins, and themes. If you’re wondering what happened to languages, you’ll read about that in a little bit.
Speed
Probably the biggest criticism of Vanilla 1 was that it slows down under heavy load. I absolutely refuse to give up on object-oriented programming in PHP, so I’ve been exclusively working with the latest releases of PHP; taking advantage of it’s speed with OO programming. I’ve also done a ton of research on code optimization for PHP. Rest assured, Garden is veryfast. But application speed isn’t where the conversation should end.
I’ve also worked very hard to produce libraries that are fast and easy to work with. I wanted it to take fewer lines of code to accomplish both difficult and common tasks. For example, I’ve completely rewritten the database libraries so that building queries is easier, and it integrates with the MVC code so that models are instantly created simply by referring to the tables they represent. This means that data validation can be automated based on the properties of columns in database tables – just one of the many places that Garden will speed up your development time.
Models, Views, and Controllers
When I was writing Vanilla 1, I didn’t know what an MVC pattern was. Little did I know that I was re-inventing the wheel at the time. Vanilla 1 used a bloated, red-headed step-child of the MVC design pattern. Garden is still based on the MVC design pattern, but it is done with far less code and in a much more elegant way. When I began re-thinking the page delivery model for Garden, I decided to go out there and research what the competition was doing. I read books on design patterns, read blog entries about everything under the sun by developers from all around the world. I looked into every framework I could get my hands on.
I ended up being a little wowed by the simplicity of CakePHP and CodeIgniter’s approaches to MVC. In the end I’ve borrowed ideas from both and added a few of my own. The result is views that can be delivered in-page or via ajax popups. Dynamic content delivered in a myriad of ways. Fully integrated protection from exploits and CSRF attacks. Master/container views that allow theme authors to quickly and easily put Garden applications right into their own applications. Simple models that can be generated on the fly. And custom routing so that pointing users to different parts of your applications is dead simple.
Membership, Roles & Permissions
While I had done some very different things with roles & permissions in Vanilla 1, I had also painted myself into a corner that made expansion difficult. In Garden, adding new permissions is dead easy, and users can be assigned to more than just one role. There are many different ways to set up registration and add new users. Four out-of-the box options are: simple (apply and you’re in), captcha, administrative approval, and by invitation.
Localization
While I believe that localization was one of the things I got right in Vanilla 1, it didn’t have any follow through. The result of this lack of follow-through is that Vanilla 1 is still released with just one language available. Another problem is that whenever the application changed, or new extensions were added, there would be the need for new translations to be in place – but no way of notifying the translation authors that these translations were needed.
In Garden, the localization files are roughly the same. One difference is that the folder name for a set of localization files is based on the already known and followed internationalization codes used everywhere on the internet. So, for example, the locale folder I’ve been working with is labeled “en-CA” for “Canadian English”. The major difference is that localization will no longer be represented on the add-ons site. Instead, the Lussumo community will be in charge of localization.
One of the many applications I am building with Garden (alongside Vanilla, of course) is a localization application that monitors any translation that is made by Garden and records it in a database. Any member of the community can then work on any set of locale definitions they want to. It will be a wiki-like handling of localization. Whenever a full set of translations is finished and approved by a group of members, it will be added to the appropriate application or plugin and be included in the downloadable application package.
So Much More
With literally years of deep pontification transformed into code, there is so much to tell you. I still haven’t even touched upon Garden’s error-handling, out-of-the-box friendly urls, new licensing model (still open source and free), database engine integrations, cache management, jQuery! I haven’t even mentioned menu organization, plugin management, enforced plugin and application requirements, automated setup and installation. And I have only hinted at the other applications that are coming along with garden besides Vanilla. I never even told you about the hosted solution I’ll be offering when Garden and Vanilla are released!
The long and short of it is that the hard work is done. Aside from cleanup and debugging, the Garden framework is up and running and I am now into application, plugin, and theme development. My hope is to have an entirely new lussumo.com launched within the first quarter of the new year. In the meantime, keep checking back here for more in-depth previews of Garden.
