mikhail panchenko / blog

The idea here is being able to route ked_core to a static template w/o executing any action or having defined one. For example, if you want your header to just be static HTML and want that in a separate header.tpl file, there’s no reason you should have to define controller->header() just to access that.

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);

which would then just be handled and displayed nicely with ked’s exception handler.

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)) { ...

No. That is clearly a file system operation that will be run every single time, even though we know that 99% of the time, unless the developer is a total and complete dunce, the template is there. Then there’s the additional fs read to load the template.

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')
...

I just check for the presence of the warning and throw an exception if it’s there. Now, normally, I am not a fan of throwing exceptions, but in this spot it’s ok, and I’ll explain later why. The short explanation: because we’re not catching it.

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;
}
...

So here, we just try to create a ReflectionMethod as we normally would for the action, but if we see an exception, we just return; out of _execute and go on to _render. It’s sort of sloppy (because what if ReflectionMethod’s __construct() threw an exception for some other reason) and the real problem is this: we are creating and catching an exception in framework code. Every time an actionless view is called, this will happen. David pointed out that the exception is itself an object and can be quite heavy.

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;
}
...

We just check if the method exists; if not, we set a variable that tells _render to forego assigning template variables that would have been set in the action had it existed and return false. (Right now, just returning would suffice, but I feel a disturbance in the force that tells me that this false value will come in handy somewhere down the line).

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
...

We check the bool we set earlier and forego template var assignment if it’s set to true. Once again, the exception is fine because we’re not catching it, and this is meant for exceptional cases that are supposed to grind our application to a halt. Unlike the case in _execute, this wont’ be called every time there’s an actionless view – just in the case of an error.

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.

Over the past couple of weeks, I was hacking up an MVC framework, mostly for my personal use. I am gonna post the code once I’m done, however. I have decided to go back basically to the drawing board with it, and don’t feel like starting right now (on “vacation” in SF) so I’ll just write about it instead.

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.