Vacation was great! It’s good to be home though.
I’ll blog about it later and possibly post some pics too.
ClayDB, Input Validation and Filtering
I’ve been really busy with my career job lately, but I have managed to do a few things with Clay. ClayDB is coming along nicely; its intended to be used with PDO and currently supports the PDO_SQLite and PDO_MySQL extensions. ClayDB also has a wrapper class that allows you to use its simple query functions with other abstraction layers. Creole is included for example and will be supported in the foreseeable future. The wrapper class gives us the advantage of supporting as many database extensions as possible, without compromising our plans for ClayDB. As a developer you gain the advantage of using the native PDO or abstraction layer functionality, along with ClayDB’s query functions.The datadictionary capability of ClayDB has gained some strength as well.
I am slowly rolling the stuff out that I felt Clay needed before a Beta release. Input validation and filtering is an important feature Clay has lacked until recently. I’m using a method of variable fetching/validation similar to Xaraya’s, except I think Clay’s method is a little more intuitive and easier to use. This area has been my main concern for a beta release and it is well on its way.
I’ve begun setting up a section on this site for Clay Framework, which I will try to begin filling in soon. I’m thinking of waiting until the 0.5 beta release to publish a roadmap, although I may go ahead and put one up for the initial beta itself. Overall I’m satisfied with progress, although I wish I had more time to work on it.
I’ll be away for about a month, beginning around May 18th and returning around June 15th. When I get back I hope to dig in for some heavy coding sessions and get the first beta rolled out.
Posted in Blog.
Random Thoughts for the Day
Although I haven’t had a lot of computer time lately, I’ve really been enjoying the new Ubuntu. It seems to run better than the version I had to drop and I haven’t missed Windows at all this time. Wine is finally working for me this time around and I’m currently installing Eve Online. We’ll see if that works out or not here shortly.
I’ve had way more time to think about Clay than to actually work on it this month. One of my bad habits is to never let something fully materialize before I begin redoing it. Clay has kind of fallen victim to my bad habit. Luckily this time I’ve done more thinking than redoing. So, one of my priorities right now is to write up a road map for Clay 1.0 and decide how to step it up from 1.x to the new ideas for Clay 2.0. One of the things I have to keep reminding myself is that Clay is a framework, not a CMS. My focus is currently 90% framework (libraries, modules), 10% applications available. As Clay matures, during the 1.x phases for instance, I’ll shift the focus more to applications.
I want to get into desktop software development. I’ve looked at a few languages and I don’t feel like I’ve learned enough PHP to begin splitting my time just yet. One thing I’ve considered is adding PHP-GTK support to Clay, or perhaps just creating a new version of Clay specifically for PHP-GTK. Just a thought, but I think it could be a pretty good thought 
That’s it for now… sleepy time for me.
Posted in Blog.
Ubuntu 9.04
I’ve been needing to test the Clay Framework on Linux, and didn’t want to put it on my host’s server, so I decided to give Ubuntu another try. I’m really impressed so far, although I’ve only been running it for 15 minutes. I had to revert back to Vista, which I later reverted back to XP, back when Ubuntu 8.04 was released. It was just too glitchy at the time.
I back on the boat now, hopefully I wont going back to XP except for testing Clay
Posted in Blog.
Clay Status Update
I’m still working on it I’ve cleaned out a lot of test code and transitioned entirely to ClayDB. Currently ClayDB only has an inteface for queries through the PDO_MySQL driver, but it should support SQLite soon as well. I decided to start out with PDO, instead of the native drivers, but I plan to eventually add support for mysql and mysqli. PDO has quickly become my favorite though.
I’ve been toying with the DataDictionary, but real life work has hampered my efforts in getting a lot finished on Clay lately. One of the features I’ve experimented with is type casting DB fields. Basically, if you need a primary key column you just specify ‘id’ as the field type and the class fills in the rest when the table is created. Same goes for when the needed field type is ’string’, ‘numeric’, ‘integer’, or ‘boolean’. One of the ideas for later on is to map types so when you create a table the data types are always validated for queries.
I’ve done a few other things here and there, but those are the most significant. Until next time…
Posted in Blog.
Clay Framework Status Update
I’ve been grinding away at the ClayDB abstraction layer, but it’s mostly been experimenting. I do have some solid methods going and have began adding the new calls here in there for testing though. So far you can do anything basic with a single line of code. For instance:
$profiles = $db->get(’fname, lname, jdate FROM profiles WHERE userid = ?’, array($userid), ‘0,1′);
will give you one row as:
$profiles['fname']
$profiles['lname']
$profiles['jdate']
delete(), update(), and add() are available as well. I hope to be able to implement something similar for transactions, more than likely splitting the queries with arrays. I have other plans as well, but those are the ones I’m worried about for now.
I kept bouncing back and forth on whether or not to go forward with ClayDB, even replacing Creole with dbFacile and then undoing it. Needless to say, I’ve prolonged the inevitable and ended up only wasting time. Fortunately, ClayDB is the fastest I’ve used so far (for development and performance), I guess time has to be made up some how.
I’ll try to start posting a little more regularly… no promises though.
Posted in Blog.
Introducing ClayDB
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.
Posted in Blog.
Drawing Board: Help and Support System
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.
Posted in Blog.
Regulating Global Population
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?
Posted in Blog.
JS and CSS handlers in Clay
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.
Posted in Blog.
Recent Comments