David Dyess .com

The last several weeks I’ve been looking for a DBAL that fits the Clay Framework best. I was leaning toward the ORM models, specifically Doctrine and Propel. While I like the idea behind ORM, I don’t like the way it has to be implemented right now in PHP. It will get better moving forward from PHP 5.3, but licensing has also been a concern. Clay will be released under the MIT license, which is better for the community, but harder to maintain from a developer standpoint. I like Creole, but it doesn’t fit well into the way Clay handles everything else. These and some performance concerns have nudged me onto a path to develop a new DBAL.

ClayDB will be independent from the Clay Framework, therefore it can be used in other projects without any modifications. It will include a Data Dictionary, for creating database tables, and interfaces for adding new adapters/drivers. Initially it will only support MySQL, from the mysql extension, and I plan to add support for mysqli and pdo_mysql early on. I’ve just begun the planning stages for ClayDB, so I don’t want to go into any details just yet. Primarily I want a DBAL that can take away from the monotony involved with database querying and get rid of as much code replication as possible for APIs. I also want to use interfaces that will allow a smooth transition to ORM, once PHP can handle it correctly.

So that’s where we are right now. I’ll try to get some example code up soon to show it in action.

I feel help systems are important in any type of software, but especially in open source solutions. The more you can assist a user or developer learn how your software works, the more likely they are to use it or contribute to it, in some way. Unfortunately, most developers are too busy writing the software to spend a lot of time on user and developer guides. I hope to find a happy median in Clay.

While it may be a milestone or 2 down the road, I have been thinking a lot about how to set up a help system that is easy to setup, use, and edit without taking a lot of time away from development. If Clay is successful, then there will be applications, libraries, modules, etc released (or at least created) by 3rd parties, so we have to insure our help system accommodates those as well. Vaguely, I think a help system should provide a single point of contact for things like compiled user guides, form helpers, FAQs, overviews, and tutorials. It should also use permissions in a way that users can see what they need, but not have to sift through things they don’t have access to.

That’s just a few things I’ve been thinking about, in regard to the help system. It will be a little while before we’re ready to implement, but it doesn’t hurt to look ahead some.

I know it sounds like I’m going to talk about how the world is getting over populated or something, but I’m not

I began last night setting up a simple debug tool for Clay and ended up rewriting all of its $GLOBALS so the data is stored in a static variable instead. I hadn’t realized how cluttered the $GLOBALS had gotten nor how some of the keys seemed to just jumble together. I’ve reassigned everything, that was getting manually assigned to $GLOBALS, to a variable in the vars class, but will likely do some more separating. I’ve heard both sides of the “store it in $GLOBALS” / “Keep $GLOBALS clean” debate and, other than when viewing the debug tool, I really don’t see much of a difference. It looks “prettier”, I guess, and sometimes that’s enough. I don’t really care for a debate, I just wanted to make debugging easier…

As Forrest Gump would say, “Good, one less thing to worry about.”

Who can debate with that? 

One of the things that have bugged me for a while is having Javascript files loading in the Clay themes, instead of per application. I had become accustomed to JS on-demand, thanks to Xaraya’s base-include and my xScript module for Xaraya. I decided to fix that this week.

I wrote 2 classes to handle JS and CSS, although they will likely be put somewhere else or even merged later on. In the process of creating the classes, I added a ‘common’ folder to the web root directory, which is for style sheets, JS, images, templates, etc that do not belong to a specific application (such as this case). I don’t have theme-specified overrides working for common yet, but that’s another story. Anyway, the JS and CSS handlers work the same as Xaraya or xScript, for the most part. They don’t have the more advanced features of xScript, but those will come. One of the things I’ve done a little differently is add a mode setting for how the JS and CSS is handled. If ‘external’ is selected, the files are linked within the page. If ‘internal’ is selected, the files are included and the code is placed within script or style tags. The later doesn’t look as pretty, as far as the HTML source goes, but the fewer HTTP Requests seem to make difference.

There are a few kinks to work out and some naming conventions to finalize, but overall the new handlers have made a big difference. I do have some features to add, but I’m not sure when they will fall in. To name a few: most of xScript’s features; code packing/minifying and caching; and the theme specific overrides. This was one of the few issues remaining that have been stalling the 0.5.0 release.

Well, February has come and gone and what a difference a month makes. Clay went from a core using procedural programming and modules to [more] of an OO design, along with reduced backend.

The Sculpt template engine now occupies the tpl class, the name sculpt is only used in the namespace for its variable cache. The IAM module is no longer a module and occupies the app class, which is much slimmer. Clay still offers support for modules and is currently, mostly, static methods on the class side. Modules will likely be used for simple tasks, but can be used as a development phase for testing. I haven’t set the file structure design in stone, so things could shift around before all is said and done. Clay still works the same, minus the use of app(), api() and tpl(), along with the other functions that have moved to classes. It looks different on the file level and is easier to understand where things are coming from or going to when reading the code.

Much of the month went into shifting things around, so there isn’t a huge difference in the amount of code to show for. There has been some big improvements overall and I’ve learned a lot. Here’s to an even better March