Brian Hartsock's Blog

So, you’re designing a new feature in PHP for an application. Like most good programmers, you have a data layer and a business logic layer. But where is your security layer?

For the most part, whenever I design a new feature, all the security goes into the business logic, because the data layer should be “dumb”. Well, this is annoying because 1) I have a lot of repeat code and 2) it’s very easy to forget something. The ideal place for it is really the data layer, but this is bad practice because you limit the data layer’s flexibility.

Then, while driving to Wendy’s for a #8 today, it hit me. The perfect security layer. Unobtrusive. Simple. Elegant.

The beauty of PHP is it allows a perfectly transparent wrapper, without a lot of code. Through the use of __get(), __set(), __call(), __isset(), and __unset(), a class can be mapped perfectly to a data object. Therefore, you can just pass a data object to a security class in the constructer. Then, anytime a function or class member is accessed, perform security checks if needed.

I haven’t designed an abstract base class for this object yet, but I am going to very soon. It should help to not only clean up code, but secure the code. Definitely going to be an addition to Wack v1.

As I have mentioned before, design patterns are one of my favorite areas of computer science. Well, design patterns have a close association with web frameworks, so web frameworks are definitely another favorite area of mine. They both help speed up the development process by providing a structure for applications. Since Ruby on Rails took off a couple years ago, other web frameworks have sprung up in many other languages. None of these have met my needs at Webmail.us.

The webmail application I work on is very different than many other Web 2.0 applications, which is why most of the existing frameworks don’t work for us.

• There are no page refreshes and therefore:
  • Most drawing is done by Javascript
  • All data transfered is JSON encoded
• Email, Calendar, Tasks, Contacts, Settings are all combined into 1 application which means:
  • Large memory footprint
  • Javascript performance very important
  • On the fly loading of HTML, Javascript, and CSS is a must

For the past few months, I have been thinking about what I really need in a web framework. Just like Rails, an MVC framework would need to be the base. In Part 1, I will just talk about the MVC foundation for this framework.

Model

An ActiveRecord type object would provide the MySQL data abstraction. I have mentioned that I have been working on my own implementation for a while, so I won’t go into too much detail on this. Basically, for a complicated web application, most existing model abstractions don’t work very well. With complicated JOIN’s, WHERE’s, and subquerys, something different must be used.

View

A templating mechanism must exist to have a complete web framework. Current view abstractions won’t work in webmail. Since webmail never refreshes, going to the server every time we need to populate a template is troublesome. The templating mechanism in the better web framework would allow a template to be used in PHP or in Javascript.

If a template is used in Javascript, once it is downloaded once, it wouldn’t have to be downloaded again. The hard part about a Javascript template is the inability to have loops and the need for slow regular expression parsing.

If a template request in Javascript has to make a server request every time a template needs to be populated, speed becomes an issue. This is fine for large templates, but what about small widget templates? Making a server request for a small element increases 1. latency and 2. server load which in turn increases latency even more.

Controller

Controllers are the backbone of a web framework. I like how Rail works with a controller class where each data request is mapped to a function call. This seems effective to me and needs little modification.

Conclusion

I know what you must be thinking: Your MVC design isn’t that much different than Rails. Well, that’s true, but remember this is part 1. The MVC design is just the foundation of a better web framework. Rails is popular because it is useful, so it is definitely a good starting point for developing a new framework.

Shout out to Mike for his work on Javascript templates.

After writing this post a few weeks ago about PHP references, I realized I missed one great use for references. The example scenario is this, you have an array of array’s representing rows returned from a database. You want to convert these arrays to specialized objects quickly and easily.

1
2
3
4
5

$rows = $this->findRows();
 
foreach($rows as &$row){
    $row = new RowObject($row);
}

Basically, what is happening is we are referencing the $row reference in the foreach loop. The reason this must be done is because we want the actual $rows array to change, so we have to change all the references in it.