I generally hate frameworks for the very reason people supposedly love them. Most often, the popular frameworks try to making things generally easy, but specifically dumb. A framework should do a lot of smart things naturally for me. For example:
Code: Select all
$form->addSpecial('submit', 'Click me', 'submit', 'id="btn_submit"');
This doesn't make any sense. First, it requires a learn a completely new lingo. What is a special and why do I want to add it? I want to add a submit button. And why on earth is 'submit' in there twice. It doesn't make sense. And then there is an ID, which does me little good. I'm building an application with a framework. Here's a better way to handle this.
Code: Select all
$form->addSubmitButton('Click me');
There. Much easier, much less confusing, and much less troublesome. It also makes sense. The framework should be the one handling ID's and names and types. Not me. That's the point of a framework. Most frameworks force you to handle creation of the scaffolding, or the details. I don't want to deal with the details if I'm using a framework. The framework should have some balls and say "I'm made for building web sites!" and then focus on that. The framework shouldn't support other weird off-color things, just deal with making a web site.
Also, while I did use the php code above and suggest a replacement, it was only because it was easily available. A framework shouldn't deal with things it shouldn't have to. If I'm working with HTML, I should be working in HTML. A PHP framework should do as little as possible outside it's realm. What this means is rather than have to write:
Code: Select all
$form->addSubmitButton('Click me');
I should be able to work in HTML directly. This might mean the resulting code is longer, but it makes more sense. Consider this: your framework builds around the simple concept that HTML is HTML, JavaScript is JavaScript, and the framework doesn't try to build that. It assumes that you know what you are doing. What the framework does it bring it all together and doesn't fudge it up. So suddenly in your directory structure, you have a /forms/ directory that you place all your forms in. So suddenly rather than needing to use PHP to type out all your form functionality, you just get your form functionality from the form itself. And assuming that the HTML is well-formed, you can have the framework parse the file and generate a HTML+PHP cached copy on the server that it uses to dynamically render each time. After all, you can program the system to enter the value in this code:
Code: Select all
<input type="text" name="item" value="">
This is better than requiring people to do this:
Code: Select all
<input type="text" name="item" value="<?php echo $this->value; ?>">
Why don't you see this? Laziness. Heck, I've never done it because it would require extra work that I really don't want to involve myself with.
Basically, the point is, a Framework should do the work it can while at the same time not changing the way you work. Let people who've learned HTML write HTML, who've learned JavaScript write JavaScript. One of my most favorite frameworks that I've built for work I've done is a reporting class that has slowly evolved into a monster. But it gets the job done and stays out of the way.
First, it assumes that you are creating a report from a database (though I could easily hack it to use something else). Secondly, it assumes you've already connected to the database. Finally, it assumes that you might want more than one report on a page. Basically, to great a paginated report you do something like this:
Code: Select all
<?php
$Report = new Report("Quick User Display");
$Report->useTables("users, user_details");
$Report->fetchCol("id");
$Report->displayCol("username as Username");
$Report->displayCol("email as Email Address");
$Report->displayCol("logins as Login Count");
$Report->makeSearchable();
$Report->makeSortable();
$Report->setHandlerFor('username','makeUsernameLinkable');
$Report->cache(60);
$Report->generateReport();
function makeUsernameLinkable ( $username, $record, $rs ) {
return '<a href="Users.php?id='.$record['id'].'">'.$username.'</a>';
}
?>
This code does several things that makes things easy for the user. First, it will handle generating the HTML table using appropriate ID and CLASS attributes that allow for complete customization. Also, it determines how to link the two tables together (with ID in this case). By following a common sense standard in the database, you can have a framework that makes assumptions. This assumption is that 'id' is the PK, and something like 'user_id' is the FK. The real magic happens with makeSearchable and makeSortable. They do exactly what you think they do. They make the report searchable by the user and it also makes each header sortable. The framework automatically fills in the needed information so the user has the ability to search any of the fields (or all of them). Of course, it can also sort by each of the fields. By default, the framework is set to display 20 items per page, and handles pagination. And while it generates all the fields and IDs for you using known methods, it ensures that each report on a page doesn't affect other reports. So it doesn't use a generate "next_page" GET value (as that would affect all reports on a page, should you have more than one).
It also allows you to set a handler for any field. In this case the handler is for the username, and it makes the username a link. The framework also provides a method to cache your basic searches (It doesn't cache searchable reports 'yet', but I included it as an example).
But even this framework suffers a bit. I haven't built in the ability to use your own SQL, though this is again merely because I'm lazy, and haven't found a real need for it yet. Also, the HTML is currently hardcoded, but it wouldn't be much trouble to abstract it out (I actually started doing that, but it was boring). However, the generated HTML is pretty much what you'd get out of a table anyways, so it doesn't matter to me.
The point is, I make a lot of simple assumptions, but I believe all the assumptions are smart assumptions. A good Framework let's you get away with using these assumptions without knowing about it. A framework shouldn't require additional work simply because it's easier to program. Honestly, you say you have a framework you use now, it works well, but you suddenly want to convert it to an OO system. Why? The best frameworks I've seen are those that are designed by people who use it to create something rather than create the framework to create a framework. It's part of the reason Rails is so popular for Ruby (despite the fact that it doesn't do things the way I would do them in certain cases). Rails was created by people who were actively creating a framework not to release a framework, but working on a real project that used the framework. The result was a set of code that worked for them.
I loathe to see another Rails-like framework. Rails exists, and it exists in part in PHP as well. If someone wants to use PHP and Rails, they have their options. But frameworks shouldn't try to be everything for everyone. Rather, it should just flat out say "<span style='color:blue' title='I'm naughty, are you naughty?'>smurf</span> you, this is the way I do it, it works for people who work with me. If you don't like it, go find another framework." Give you framework attitude. Let it make assumptions. Make it work for you. If other people find it useful, great! If not, who cares? You are getting work done while they are playing with FrameworkOfTheMonth.[/syntax]