David Dyess .com

Clay’s controller has been in a state of transition lately. A few weeks ago I got rid of the static methods and made the controller a single large object. It worked OK, but after some experimenting I realized I had killed some of the flexibility the static methods had allowed. So, I went back to the drawing board. I then split the controller, which makes up the Sculpt library, into Application, Theme, Template, Sculpt, and Controller classes. Each class extended the one before it, which left room for someone to reuse the library under a different name and just swap the classes they didn’t want. It worked OK, but it was hard to read the code and know where a method or property was coming from. So, I went back to the drawing board.

The latest controller seems to be a better fit for Clay. I’ve basically combined the previous implementations, while focusing on readability and efficiency. The Controller class is a static class used for setting and returning named objects. The Theme, Application, and Template classes are mostly unchanged, other than a few optimizations. The Controller itself only manages the objects of other controllers. For instance, we load up the Theme controller by calling the method:

\clay\controller::object(‘theme’, new \sculpt\theme);

Now the Theme object can be used in any scope by calling:

\clay\controller::object(‘theme’);

Such as setting the page title from an application:

\clay\controller::object(‘theme’)->setPageTitle(‘Welcome to Hello World’);

One of the other changes in the latest implementation of the controller is I’ve moved the initialization of the Application and Template controllers out of the \clay\init function. This change is a little more efficient and allows custom configurations to be implemented a little more easily. The Application class initializes just before the Theme class begins loading it’s Page template. The Page template initializes the Template class, which leaves room for Smarty or another template engine to take over. The Sculpt class has been removed altogether, which makes it a little less confusing as far as browsing the files in the library.

My main goals with the Controller is to leave room for custom controllers, encourage optimized object models, and be as fast as plausible. I think we’re slowly moving in that direction. These changes have been pushed to the GitHub repo. There is still work to be done in Sculpt, most notably in the CSS and Javascript handlers, but also a few new features such as image handling and short urls. Please check it out and let me know what you think.

I pushed Clay Framework to Github (http://github.com/clay/clay) almost 2 weeks ago. Well, I’ve been digging through the code a lot since then and came to a few conclusions. 1) I don’t really like some of my implementations. 2) I do love the basic ideas behind Clay in general. 3) I don’t really like some of my implementations. So, I picked up my digital sledge hammer and starting hacking.

First of all, I don’t think my implementations were bad, per se, they just looked 2 years old (most almost are). Almost everything has been procedural, mostly using static class methods and variables. It has been really fast, performance-wise, but I think I can make it fast object-oriented as well. Ok, now on to the good part:

I took my App and Tpl classes, which were completely static, and merged them into a single Controller class. The reason I hadn’t done this before was because I had a misconception about the way objects work in PHP 5. I thought if I assign an object to two different variables then I’d have two copies of that object. I was wrong. I merely have two more ways to interact with the same object! So, instead of having to call static class methods all over the place, such as in an application function, I pass $this from the Controller to the application function. Whatever that function does to the object the next function can see and use as well. By using a single Controller class to control applications and templates, I’ve essentially created a singleton pattern, without having to ever store the object in a static method. I had been using a static Data class to store/transfer data between functions and classes. It was my singleton class, but now I may not need that class at all.

I had been wanting to move toward an object-oriented model, but was afraid of a decrease in performance. I had envisioned doing it using a singleton pattern and passing the objects around, but thought the objects would be individuals (clones essentially), rather than the same objects. I haven’t pushed the new controller yet. I want to do some more testing and cleaning. I’m thinking I will probably get rid of the Data class, but it may be necessary to keep on for Clay APIs to utilize. I’m almost tempted to do away with the Clay class as well, but I don’t think I’ll do that just yet. There’s still lots of testing to do, but I guess I won’t be worrying if I should have made it object-oriented anymore.

I’ll probably push the new controller in a few days. Then, maybe, I’ll begin pushing the Installer.

I’ve started pushing Clay to its GitHub repository: http://github.com/clay/clay

There is still a lot of code I haven’t pushed, for varying reasons. I’ve been changing a few things around so I’m hoping I haven’t messed any paths up. Otherwise, Clay should be usable as it is currently in the repo. The Installer hasn’t been pushed yet, because of some cleaning up I need to do there. I hope to have everything or most of it pushed by the end of the weekend. Right now I’m working on an example installation that won’t need the installer to work. It will hopefully give you an idea of how to use Clay until I get some documentation finished.

Check it out and let me know what you think. I need help too, so let me know if you want to work on it with me!

If you live in Georgia and you voted for this guy… I’m speechless.  Apparently his campaign was speechless as well, otherwise voters would have surely realized something wasn’t right.

My prediction of what the Democrats will propose as the new US flag.

Google has looked into their own sites’ search engine optimization and found they had a few problems.

The timing is kind of ironic. The past week or so a friend of mine, whom I helped build a very popular web site among Primitive Baptists, started a blog and wanted to know some SEO tips. I told him the basics and things I had tried to do with his site. Google’s SEO report card would have been handy.  They also have an SEO Starter Guide, which will undoubtedly be helpful in the future. From a quick glance at the Guide, I have been doing some things right. This web site may not be that great at the moment, but it’s always under construction.

Clay Framework had taken a back seat for a little over a month, but things were moving again this past week. Unfortunately, this next week is going to be a no-go for development. I hope to get back into it hard next weekend and try to get an alpha release out around the first half of March. I call it alpha, but I measure by completeness, not stability. I’ve been hammering out a lot of little bugs lately and adding some new features along the way.

I’ve always been one of those guys that tests the crap out of everything and never felt the need for exception handling. I always use if(empty()), if(!file_exists()), etc to keep the flow and sanity, but just never understood the need for try{}catch(){}. That, my friends, has changed. While dancing with a couple of bugs this week, I almost gave up and scrapped the entire project. It was ridiculous. One little return false at the bottom of a file, 3 directories up, was keeping my app from loading and I couldn’t figure it out. It took 3 days of dancing before I realized my appended prefix of .pbp, which should have been .php, was causing my import function to fail. It took me 3 days, because my import function didn’t tell me it failed, it just returned false and everything else kept going. Live and learn…

Clay Framework now has exception handling. I’m using the built-in PHP Exceptions, but that is mostly because I don’t really see (yet, I’m sure) the need to reinvent exceptions. I had been using a redirect to an error application, which was pretty cool since it used custom error codes. With the Error app, you could register error codes from your application or API, and redirect to the error app when needed. Unfortunately, sometimes there’s a bug that prevents the error app from loading and then you are just stuck with a return false (or I was at least). The cool thing about my use of Exceptions is it uses a bit of redundancy, but doesn’t go overboard and Clay tries to keep going. That means instead of a single error message, you’ll have as much of the page as Clay could render, with whatever exceptions shown in their respective places. It’s made a big difference already and helped me knock out a few more bugs since I implemented it earlier.

That phantom I keep calling the Clay Installer is finally becoming somewhat of a ghost. The direction it took this week is way beyond what I planned to have in a pre-1.0 build, but I ran with it anyway. Initially, I was happy having packages that defined the configuration information and then the rest of the installer was a manual install tool (kind of like Zend Server’s administration). Basically, it made Clay like the typical frameworks (Zend, CakePHP, etc), where you have the framework and just build on it however you like, plus a simple install tool. While prepping the Installer, I ran across a bug, which turned out to be a pretty cool feature. I shined the bug up a bit, put a nice collar on him, and named him the package manager. Clay’s Installer went from Lincoln Logs to Legos. What I’ve done is used a custom initialization function (yup, Clay supports that) to allow the Installer to load packages as if they are applications. Whereas before you’d name the package in the Installer, now you create a namespace for a web site, then assign a package to that namespace. Each package is it’s own installer, so Clay’s Installer is just there to lend a hand once a package is selected. The cool thing is the packages are loaded inside the Installer and are theme-able. So they can be branded and have that independent feel, but still fall back on the Installer for whatever they need. To take up the slack and preserve it’s previous manual installation feature, I’ve created a package named Custom that will allow you to “build” custom installations. I said “build” because it doesn’t really build yet, but a planned future improvement is to allow you to clone your custom package and actually build new packages.

Other than that, I updated the Installer’s ctx-1 theme with some CSS3 and just tidied up here and there in the APIs. Things look a lot better than a week ago, but I need to step it up some more. I want to have the ClayCMS package available when I release the first alpha, but I can’t make any promises there yet.

March 12, 2010 is the release date. Whatever isn’t finished by then will have to wait until the next release.

I noticed a couple of months ago my keyboard’s keypad stopped working. I assumed it was just something that was broken in a patch and the next patch would probably fix it. After dealing with the top number keys for the last couple of months (including doing my taxes), I decided to just Google it. As is normally the case, there’s an easy fix.

System > Preferences > Keyboard; Mouse Keys Tab; uncheck “Pointer can be controlled using keypad”

Here’s where Google led me to find that out, along with the references to the bug reports regarding the issue.

This installment of the 10’s Series is about enhanced GUI features. I think the two items I’m going to discuss are possible now in most frameworks and that is why I don’t think they are far-fetched. In some ways I feel we are nearing the home stretch of Web 2.0 and approaching whatever they call it next (2.5?). Web 2.0 has been about interaction and using the browser as a platform for applications, moving the web closer to the desktop. It’s meant other things as well, but I think the summation covers a lot of 2.0.The advent of Chrome OS (as well the platforms that inspired it) and the push for HTML 5 are shoving us ahead into the next.

Web OS / Web Desktop /etc.

There are lots of Web OS’ in the wild today, EyeOS is probably the most notable one. Web OS’ haven’t caught on as much as I thought they would a few years ago when I heard of them. I think we were waiting for the ‘Cloud’. I can see a web page styled as a desktop used several ways, but I think it is a logical step in the evolution of web interfaces. Imagine logging into your web site and having a desktop OS-like sitting in front of you. You have a desktop to save shortcuts to work or your favorite tools, you have a Start-like menu to navigate your site’s tools and features. You open your articles listing and a list of icons opens in a window on your desktop, each an article. You open your images or media folder and you see thumbnails instead of the old list of links. You minimize your images folder, which is now a tab on your taskbar, and open a new article. You type it up, drag an image into it from your images folder and save it. You then open your web site in a new tab or in a browser window on your web desktop and see the article on your home page.

A web desktop as an administrative interface to a web site seems like an intuitive way to manage a web site. It not only makes managing a web site more familiar, but it also opens it up to a whole new set of capabilities. I can also see the desktop being useful on the user side of a web site. A lot of people may think this seems silly and just a fad, but when I said, a few years ago, Google would be building a web-based operating system, they thought it was silly as well. Now Chrome OS is coming up quickly and it uses AppEngine, a web-based application platform. Here, I’ll do it again, Facebook will be building a web desktop. The PHP frameworks that hit it big in the 2010’s will have capabilities to launch web desktops and the apps to use on them.

Web IDE

I’ve been grappling with this one for a while now. We have 3 client computers in my house and I spend almost equal amounts of time on 2 of them. I try to use them both for development, using Eclipse and SVN, but something seems to always go wrong or I forget to update my repo. I have found tools like PHPAnywhere, but I don’t want my development code on someone’s server. What I want is an IDE, like Eclipse, built into my web site. I doubt I’m the only person that thinks an IDE built into a framework (or at least on top of the framework) would be useful and a huge boost in project development efficiency. Implemented effectively, a web IDE could virtually replace conventional version control tools. At the very least, an IDE could supplement version control enough to ease the headaches that come from managing repositories for large projects.

To wrap it up so far, a 2010’s framework should have:

• Powerful template system for the web designer (1)
• Dynamic “Core” (1)
• Flexible low-level configuration (1)
• Web-based Desktop
• Web-based Integrated Development Environment

To be continued…