David Dyess .com

According to Mozilla Labs:

Bespin is a Mozilla Labs experiment that proposes an open, extensible web-based framework for code editing that aims to increase developer productivity, enable compelling user experiences, and promote the use of open standards.

This looks like a very interesting project and one similar to what I have in mind to implement for Clay. They have a demo online at http://bespin.mozilla.com/. It looks as though you can work in code repositories, but I’m not sure of how it works beyond that.

Bespin is written in Python; there appears to be a Java version in development (or at least I saw a Java folder in the backend folder).

A few days ago I was going through the roadmap to see what needed to be updated. When I got to somewhere near the 0.7.0 milestone, I remembered I intended to transition quite a bit of the framework to OO and methods, rather than the precedural way of doing things at the time. I started thinking about how much rewriting that may require and realized it may not be such a good idea to wait that late.

I’ve always been a precedural programmer, mostly due to my use of Xaraya for so many years. Clay has always been what I think a perfect Xaraya would look like – simple and fast as hell. Xaraya has the fast part, well, it could be faster, but considering the size of the core I think it does pretty darn good. Back to the topic I decided it may not be a bad idea to learn the OO side of PHP a little better and try some stuff out on Clay. To make a long story short, Damn. I still haven’t changed all of the “core” functionality to methods yet, but each one I change chips away at the processing times.

Using methods has also given me some insight on how to set up a lot of the features I’d been planning. Before now, I had mostly been willing to persue a path similar to Xaraya as far as structure goes. Those plans are out the window and I’m getting excited Extensible = Clay. I’ll talk more about the new roadmap when I have a little more time. Things are getting interesting…

I’ve been using PHP for around 8 years now and I would like to expand my horizons a bit. This morning I looked at a few popular languages (Python, Java, and Ruby). I spent most of the time looking at Python, as it has been getting a lot of attention – Language of the year, Stackless, etc. It is also supported by a lot of hosts that support PHP, which is a plus for certain.

I don’t plan on dropping PHP, but I can see how something like Python could replace PHP as my primary tool. One of the things I really like about Python is how it comes with SQLite, not to mention the fact it isn’t confined to the web server. I’ll continue working on the Clay Framework and developing it in PHP, but I wouldn’t count out a Python (or whichever language I choose) version down the road.

I spent last night changing APIs in modules and applications. I removed the need for APIs to have component segments, moved application APIs to a central folder (within the application), and changed the api() function to support the changes. APIs in Clay are universal and called with a single function – api(), currently part of the IAM module. The api() function is the backbone of Clay, so it will likely be moved out of IAM and into the core initialization process.

I changed the primary component segment and action in applications from base_main to main_view. I think that is a little less confusing and is a better represenation of how components are broken up into segments, if needed. I primarily wanted to find a replacement for ‘base’, but as I tried different alternatives I decided ‘main’ didn’t make a very good action. With ‘main’ free, I decided to promote it to the segment.

I’m very happy with the progress I’ve made this week, although I would like to be a little further along. I plan to tweak the APIs on the module side a little more, but the application side should be sufficient for now. Creole integration isn’t complete yet, the Panels (blocks) application is still using the sql() function. There may be 1 or 2 others. I marked a TODO comment in all of the files still using sql() , but I was making the API changes at the time and didn’t pay a lot of attention to which ones they were. Luckily, Eclipse will list everywhere I have a TODO comment

I’ve enjoyed working on Clay so far, even though I don’t have a lot of apps to play with yet. The 0.5 milestone is mostly about the framework. The 0.6 milestone brings module APIs to the table that will be needed to support applications. The 0.7 milestone begins the shift toward a focus on applications and, well, I haven’t written the rest of the roadmap yet, but the trend will likely continue. Tonight I plan to work on the javascript/css loader and templates. If I can keep this pace, we’ll have a beta release in March.

One of the things I like about my design approach to the Clay Framework is its compatibility. I’ve written a lot of the code so it could easily be transplanted into other projects. The sessions manager is a simple example – I needed a sessions class that supported Creole, but had a hard time finding any examples on the Net. I didn’t know a lot about sessions in PHP, just the basic security and setup stuff. It took almost a week of going back and forth to finally build a small class for PHP sessions and using Creole for the database abstraction. Another example is the Sculpt templating engine I’ve developed – it’s a pure PHP templating engine, very light-weight, and very fast. It can easily be modified to be self-sufficient and released as a standalone templating engine. Sculpt currently depends on 3 functions (if I recall correctly) from another module in Clay.

As Clay progresses I plan to release bits and pieces to the community. I prefer that approach to an alpha release and I think it serves the community better than hoarding the code in the meantime. The training I had to do for work the last 4 months of 2008 threw my release cycle off, so it will still be a little while before Clay is ready for a beta release.

Some may wonder why I’m using WordPress, when I’m currently writing my own PHP framework. It’s simple – I like to promote open source software. I believe OSS is a great thing and opens the door to some really great tools. I could put together a quick blogging application and use it until the Clay Framework is ready, but why bother? WordPress is, in my opinion, the best blogging software on the market so I use it. I may move to something more project focused or eventually write a ‘ClayPress’. For now I would rather avoid the distractions and just use something that works. I also have BeSquishy.com, which offers blogs, but it’s not finished and won’t be for a while. Plus, BeSquishy doesn’t support personal domains (yet) and I like to use Tangant.com.

So the short answer – it’s open source, I can blog, and it works.

I’ve been working (on and off) on a PHP 5 framework since around August ‘08. One of the its strengths is being light-weight with very little overhead. Over the last several months I’ve analyzed my choices thus far, searching for ways to make Clay better and keep it slim.

Creole Integration

My original intent was to create a small abstraction layer for MySQL and leave the holes to fill in for other database backends. The DBAL I created works well, but does not compensate for differences between the various databases within its API. I foresee that issue to be a barrier between developers who have a database preference, as most do, and have decided to move in a different direction. Although Creole is a “dead” project (as noted on their website late last year), it is very powerful, light-weight, and stable (permanently). I’m sad the developers are leaving it behind, but it offers us an opportunity to build upon their work and continue it as it serves us best. Creole integration is almost complete, it should be finished this weekend.

API Handling

Clay currently supports APIs from modules and applications to be called dynamically from anywhere within the famework. One of the changes I’m working on will separate the APIs from other segments within a particule component. In plain English, if a component named Publisher contains the segments News, Blogs, and Documents, then the APIs for those segments would all be located in folder named API. Originally the APIs were located in the segment folder, which made it difficult to quickly know the APIs available for that component.

Minimalizing Legacy Support

As Clay grows over time and matures, I don’t want it to become bloated with legacy support for previous editions. One of the project’s goals is to design Clay so that standards are in place to mediate between the framework’s various components (currently modules and applications). Those standards should minimalize the affects of changes during a version’s lifetime and promote innovation for future editions. I believe innovation shouldn’t be cut short to compensate for present/past conventions or mistakes.

Project Hosting

Clay as a project is currently hosted on Google Code/Groups. I’m considering moving it to SourceForge or someplace similar. Google is a little too loosely coupled for our needs. I’ll continue using Google for the time being, but will likely move the project elsewhere shortly before our first milestone release.

I have more to talk about, but I should get back to working on Clay I’ll post updates as time allows and let you know where the project stands. Hopefully I’ll deem it release worthy before too long…