As Crowley put it, that is overkill. I know. But I need to learn how to write PHP extensions

I realize that I’ve started more projects in the last month than I have in the last 2 years. I am going to prioritize things a little bit – I want to focus on ked_duffel (the SVN delivery system) to start out, then once that’s functional use it to update mihasya.com’s framework files, then tinker with the framework a little bit, using duffel to test it on mihasya.com.

Once I’m happy with its functionality, I’ll start compiling a pecl skeleton and trying to fill it out, making heavy use of my rollover minutes – to call Crowley with dumb C questions.

Of course, all of this is going to have to wait a little bit – I realized recently that nearly two weeks had passed without me having done any paid work. Someone has to pay for Crowley’s lapdances, so I am going to dedicate a bit more time to Yahoo! stuff in the coming couple of weeks.

I went through several iterations on this code (some of it is in svn, though not all – I had to start the repository over b/c I forgot to add trunk/ branches/ and tags/ ) so here is my approximate thought process.

Step 1: Check the .tpl exists

I should have had this check anyway, but before I did not realize the need – there needed to be an action defined for the view to be rendered anyway, so I focused on that, and that seemed to take care of itself. The following line would just throw an Exception

$reflector = new ReflectionMethod($this, $action);

But now I really do need to actually handle this on its own, since the action might not even exist – WHAT WILLS WAE DO THARN?!

The Wrong Way:

if (ked::$smarty->template_exists($tpl)) { ...

The Right Way:

The right way looks sort of hackish, but bear with me. Smarty is really dumb about how $smarty->display() works. It never returns anything. If it fails to load the template, it prints a warning. Can’t really check to see if it succeeded in any robust way, so this will do:

...
ob_start();
ked::$smarty->display($tpl);
$viewContent = ob_get_contents();
ob_end_clean();
if (!$this->_skipAssign) ked::$smarty->clear_all_assign();
if (strpos($viewContent, "<b>Warning</b>:  Smarty error: unable to read resource:")!==false)
  throw new kedException('The view "'.$this->_view.'" was not found')
...

Step 2: Make _execute Not Choke On Absent Action

The Wrong Way:

This is where I originally threw an exception, but a comment by David Hall made me pause.

...
try {
  $reflector = new ReflectionMethod($this, $action);
} catch (Exception $e) {
  $this->_skipAssign = true; //tell _render to skip smarty->assign related steps for this.
  return false;
}
...

The Right Way:

This caused me to revert to my original intuition for how to do this:

...
if (!method_exists($this, $action)) {
  $this->_skipAssign = true; //tell _render to skip smarty->assign related steps for this.
  return false;
}
...

Step 3 (bonus): Make _render More Efficient

I alluded to this in an earlier code snippet: now that we can know for sure if an action has been executed, we can do this:

...
ob_start();
ked::$smarty->display($tpl);
$viewContent = ob_get_contents();
ob_end_clean();
if (!$this->_skipAssign) ked::$smarty->clear_all_assign();
if (strpos($viewContent, "<b>Warning</b>:  Smarty error: unable to read resource:")!==false)
  throw new kedException('The view "'.$this->_view.'" was not found');
$this->viewContent = $viewContent;
$this->_skipAssign = false; //reset this to make sure subsequent actions don't get tainted
...

What Did We Gain From All This?

Well, I listened to a bunch of really fucking good music on my ipod while doing this, so that’s good enough for me. But seriously, I also ordered like 6 Threadless shirts.

Also, as a side benefit, the framework now supports actionless views without any extra file system operations. It is also wise enough not to bother assigning template variables if the template is static. You also don’t have to define anything special in the controller (in fact, nothing at all is needed there) or in the template to accomplish it – just put the static .tpl file in the right folder under inc/tpl/views.

I also used the word “tainted” in the comments… which is pretty close to “taint”… which is the area between the ass and the balls. That’s a wrap on the day.

So as I was working on mihasya.com, I was simultaneously tinkering with ked_core – a natural thing to happen, since mihasya.com is a test for how ked_core actually does when used in practice (it kicks ass, fyi). I got the idea to permit actionless views (more on how, once again, I did that better than you later), so I got all excited and immediately hacked up the code. So now I had this code that was directly applicable to mihasya.com (a lot of the inner pages don’t do much, so don’t need a controller function defined) in the ked_core svn, but not on the site.

The problem is: now that ked just ships as a big hunk of folders with the internal files and the site’s own files mixed in, the separation gets tricky. Also, my blog/ folder (the WordPress install) had to go under mihasya.ked/www/blog, as that was what my mihasya.com folder was symlinked to… Long story short, I straight up deleted mihasya.ked. That was fine, I thought, because I still had all that code in svn…. OOOOPS. Thank goodness for database storage.

Where This Leaves an Ambitious Mother F@#$%#

Well, this is a problem I gots ta solve. It’s plagued me for years, as applications come shipped in huge tarballs that just extract like they’re kings of the world. If you want to selectively update something, you have to cp files one at a time. Fuck that.

How do I elegantly, and from within the framework, permit the developer to upgrade ked files, but not affect his own? This could be solved easily by some sort of package manager like apt or rpm, but we don’t have that luxury. Or rather, I won’t give myself that luxury. This will be solved with bash, php, and svn in the spirit of minimalistic requirements. After all, it has to work on Dreamhost

What I Intend To Do

This is how it’s goin down, homegirls: I am going to write a shell script which will fetch a special file from a predetermined svn location (the repository doesn’t have to be static, as I’m sure ked will have thousands of mirrors as it sweeps the market ) The file will contain a listing of files which are internal to ked. It will probably just look something like this:

...
inc/controllers/internal
inc/core
inc/tpl/layouts/internal
...

One problem I’m already seeing before I even start hacking this up is that www/index.php contains configuration information that I refuse to move into a conf file (extra file read) that might get overwritten in this way, but I can probably figure out a way to handle that without quite developing a full blown package manager variable manipulation deal. Or maybe I’ll just do that. Cuz I can, son!

Stay tuned for more on this and other ked shenanigans.

All code for ked_core and my other projects can now be found here.

Slight change in nomenclature (aka stuff I hate) – the package that contains the framework itself will now be called ked_core, to accomodate future projects like ked_pdo and ked_auth that will play nicely with the framework. Those will have to wait until I un-dumbass myself by doing some more reading. And just completely stop giving a fuck about school and dedicate all my time to hacking.

Some General Thoughts

I’ve decided I can’t call it an MVC framework – because I don’t believe in models in the way Rails does. I don’t think an application has to be based around a model. Just because Rails has a built in implementation is not a good reason, to me, to use one. I have legitimately written an application that was very useful, but used NO database whatsoever. Anyone is free to use a 3rd party model implementation or write their own, but ked won’t require one by default.

Change in Goals/Scope

So as I was fucking around with the code, I decided to stop and revisit my goal: building a framework that can follow a site as it grows from something completely tiny hosted on something like Dreamhost to a massively scaled site with its own farm. For that two things are needed: leanness (least possible number of required operations and disk reads/writes per page load) and maintainability. The overall goal is now to be able to just download a ked skeleton to any host with PHP5 (I’m using my 5.95/mo Dreamhost account as a benchmark; if it works there but not on your host, kill yourself), then be able to grow it from there and move it to any other host near seamlessly. The changes to the core are as follows:

• ked will now only run through a single index.php file, which will then load all the appropriate files for all the controllers. It ends up actually being 1 fewer include per page, thus one fewer fs operation. I realize that isn’t a big deal if APC is involved with opcode caching, but remember – every little bit counts.
  • no apache configuration needed beyond RewriteRules in .htaccess.
• ked now also supports grouping controllers/views into folders. Naming your controller admin_mainController adn placing it into /ked_app_root/inc/controllers/admin/main.php will work. Your views can then go into /ked_smarty_dir/templates/admin/main/viewName.tpl.
• Similar functionality for layouts.
• ked_core is still probably ~100 lines of actual code. Everything uses single quotes and only basic string operations – no regular expressions except in my print_r wrapper dump(). There are minimal advanced functions used – one instance of reflection, I believe.

My general stance on what ked will/won’t do also changes, so it will INDEED now wipe your ass for you for the sake of maintainability.

• ked will generate controller/view skeletons for you via a webbased control panel (pending user permission limitations – to be investigated)
  • if PEAR_DocBlockGenerator is installed, it will use that to generate docblocks for those skeletons
• ked will support phpUnit integration (but obviously won’t require it) as well as svn hooks to automatically run the unit testing and append test failure notices to the -m msg, citing who committed the failing code.

To Be Done:

• the basic ked_admin package for skeleton generation/management (which will, btw, use ked_core )
• rewriting mihasya.com to use ked_core to demonstrate TEH POWAERS, hence its presence in my subversion tree – you’ll be able to compare the original tree with the ked’d tree.
• investigating integration with PEAR_DocBlockGenerator, phpDoc, phpUnit, Subversion, and my taint.

Why? Aren’t there enough?

Yes, but I can never quite get what I want. Here’s a breakdown of my reasons.

Complexity/Usability

Cake does too much. Zend is a little more lean, but does things in a dumb way that requires lots of typing for really simple things (Zend:RD Frameworks::YUI:JS Libraries), Symfony just just didn’t appeal. There’s actually a pretty good feature comparison for 10 frameworks here. My basic complaint is that they all have too many checks for features. I think I just disagree with the use of the word “framework”

I’m a big fan of the 37signals guys and their general design/development philosophies. However, I think that with Rails they’ve strayed from their own philosophy of doing less, at least from the point of view of an external developer. From their perspective, it’s fine because they build Rails to do EXACTLY what they need, so it works great for them. But for a developer starting to develop his own application, Rails is the Microsoft Office of frameworks, and all the PHP frameworks followed Rails into intense complexity, even calling themselves “ports” of Ruby on Rails.

I’m all for not solving the same problem twice. But I don’t think very many problems are ever the same in the strict sense.

Scale/Performance

The more built in features your framework has built in, the more difficult it is to “stray” from the framework. Cal Henderson (OH SNAP, NAME DROP!) writes in his book on scalable websites about striking a balance between OGF (One Giant Function) and OOP.

As you move further right [towards OOP], you gain maintainability at the expense of flexibility. As you move left, you lose the maintainability but gain flexibility. As you move too far out to either edge, optimizing your application becomes harder, while architecture becomes easier. (13)

Cal classifies things like Rails towards the right; in my opinion Rails along with PHP clones like “PHP On Trax” fall way too far to the right.

Relatedly, this causes a concern for scale. Sure, it’s nice to be able to develop your application quickly and save the $$ and time (so, once again, $$) from your development budget, but you gotta remember – servers cost money, and your application will need servers for as long as it’s live. If you are lucky and your app takes off, you will very quickly realize that every extra little bit of overhead adds up. If your framework just decides to load sqlite on every page view even though you aren’t using it, you’re going to notice (I’m sure there IS a way to turn this off, but Rails would not function until I installed the sqlite3 gem despite the fact that my entire database.ini was mysql). Every file read/write ends up counting.

My goal in creating this framework was to balance usefulness with performance. It does what I think are crucial things to rapid development, but everything that the most basic application ever can live without is left to plugins. If your application doesn’t use databases, you don’t have to define any database confs.

Also, features like “AJAX” are not appropriate to a PHP framework. A PHP framework should facilitate PHP development. Not write JS code. Not rewrite URL’s (hello, mod_rewrite), etc.

Ease of Installation

I’ve only had to install Rails, Cake, and Zend and was just underwhelmed by how much work it took just to get things started. In my interpretation of it, a rapid development framework should allow for a quick start. If it takes me days just to get the damn thing to “Hello, World!” it’s really not worth it.

Dogfood: The Best Reason

The other frameworks just don’t suit my needs. I’m about to knock out a couple of quick freelance projects before I fully transition from student to “real person”; one is very small and simple with minimal db interaction and a tiny CMS component. The other is quite a bit more complex, with a fairly elaborate hierarchy of pages. The first one obviously doesn’t fit the bill for any of the existing frameworks. The second seems like it (I initially was planning to use Cake when the project was first discussed last spring) but actually messing around with cake proved that I would absolutely hate doing an entire project in it. I needed something simple that I could use over and over on projects of varying complexity without taxing the simpler ones with excess complexity.

So Tell Me More!

OK OK! Here’s a little info on the yet-unwritten barebones mvc framework.

The Basics

My baby is due in about 2 weeks. She’s going to weigh in at about 300 lines, probably including doc blocks. Yup. No more. I agree with Crowley’s assessment: if it breaches 300, start cutting back. That is exactly what happened. I was getting a little trigger happy with the plugin system and just starting confusing myself. “Uh oh,” I thought. “If I’m confused, how will an outside user feel trying to figure this out? Actually fuck em – if I’m confused, I’ve written a bad framework, because it should satisfy me first and foremost.”

I’m going to name it Ked. Why that name? Because it’s short easy to type – 2 of the letters are on home row. Just try it: ked ked ked ked::dispatch ked::$settings… it just rolls off the fingers.

There is, however, a metaphoric component – I didn’t get three liberal arts majors for nothing. Keds are my favorite type of footwear. They are very basic, they are comfortable as fuck, they are good for most situations in life (well, if you’re a programmer and don’t have to dress up for work, anyway), and they will rarely let you down. They are perfectly designed to fulfill a very simple function – cover your feet as you walk around. You can, however, put diamonds or Gucci fabric on your keds if your needs call for it. They’ll still be keds, and will still serve their basic telos but will now also serve as a fashion accessory. If you went to high school in the 2000′s, you just think keds are cool no matter what, but that’s neither here nor there.

This framework will aim to be the ked of frameworks – dependable and simple, yet perfect for its one function and extensible to fill whatever other role you need it to.

The goal is to require as little work for every page view as possible, allowing developers to add additional functionality on a per-controller and even per-action basis.

So what’ll it do?

Well, here’s a list of things it won’t do:

• Make you a mayonnaise sandwich
• Interpret and route pretty URLs. Use mod_rewrite, it’s faster.
• Write your XHTML/CSS and JavaScript for you
• Load a bunch of code to handle databases that you don’t use on every load
• Make you type 2 lines of code to do something dumb like set a template variable.
• Make you change your Apache config. Though using some Apache settings is recommended from a performance stand point, Ked will run on anything that runs a reasonable configuration of PHP5.1+ (5.0 might work, but I haven’t thought about it)
• Wipe your sysadmin’s ass by being backwards compatible to PHP4. Ked will use some very new and cutting edge tricks to make your life easier. If you are on a host that still runs PHP4, find a new host. Adding checks for PHP4 fail will inevitably inflate the otherwise trim code base.

Fine, here’s what it WILL do:

• Separate logic from presentation (DUH) and direct traffic appropriately
• Provide an easy way of passing variables. $this->var in the controller will bind to {$var} in the Smarty template (don’t worry, not all $this-> variables will be accessible from Smarty)
• Use Smarty. Smarty rules. Don’t fight it. Though someone is welcome to write a plugin that allows Ked to run w/o Smarty.
• Uhhh… oh yeah, allow some funky plugin interaction.

Pretty short list huh? Yup. It’s a ked.