Blog

The problem with PHP frameworks
Posted by admin in Programming on 01.02.07

In my last post I tried to articulate some of the things I’d like to see in a PHP framework. Youngj posted a comment and suggested that I try Qcodo. I have a problem with Qcodo’s template system, and it is a problem that I have with a large number of other PHP frameworks: HTML that gets embedded in the PHP code (also known as PHP code that writes HTML). I’ll let this criticism of Qcodo stand-in for my criticism of all PHP frameworks that do this (which is most).

Please consider the example Qcodo gives on the front page of their site:

<? $this->RenderBegin(); ?>
Id: <? $this->txtId->Render(); ?>
Title: <? $this->txtTitle->Render(); ?>
<? $this->RenderEnd(); ?>

Bad. Really bad. Not from a programming point of view, perhaps, but from a work flow point of view, in a professional web design firm. In this example, the form is no longer being controlled by the designers. What happens if the designer decides that the Title should have a red background, but they don’t want to change the CSS values for all inputs on the page, so they need to give that particular input an id? They then need to come to me, the programmer, and say �Could you add an id to the Title input?� Thus, work is shifted from the designers to the programmers. This is bad economics, since in most web design shops the programmers are paid more than the designers. And why would I want extra work? Why would I want a framework that puts more work on me?

When the PHP code writes HTML, the programmers end up doing work which the designers can do better.

Much better would be something like this:

<form method="post" action="index.php">
Id: <input type="text" name="id" value="< ?= currentValue("id"); ?>” />
Title: <input type=”text” name=”id” value=”< ?= currentValue("title"); ?>” />
<input type=”submit” value=”Update this article?” />
</form>

This block of HTML is something the designer can control. What happens if the designer needs to add an id to any of these HTML elements? They can add it on their own, without bothering the programmer. And what happens if the client decides that the value of the submit button should be reworded? Who does the work go to? The designer or the programmer? Qcodo sends the work to the programmer, but in my example the work can go to the designer. That means Qcodo is bad economics, at least from the point of view of a professional web design firm.

I might ask why something like this is so popular among web application frameworks:

Title: <? $this->txtTitle->Render(); ?>

I believe that the programmers who write pages like this (and I used to be one of them) are hoping to achieve productivity gains by automating some of the work of creating forms. I believe this is a false economy. I don’t see that the number of characters is dramatically less in the Qcodo example than in my example. Whatever small gains Qcodo makes, they are lost as soon as a designer needs to come to a programmer to request a change.

I do believe these frameworks (such as Qcodo) achieve real efficiency gains if the programmer is working as a freelancer, and does both the programming and the designer work. If I was a single individual, unattached to any company, then I would probably use a framework with a template system just like Qcodo (in fact, I did, when I was just starting out). These template systems probably save programmers some time, but they waste time when non-programmers need to edit the pages. In a professional web design firm, one that handles large sites and therefore must have multiple people working on the site, I believe the best bet is to stick as close as possible to pure HTML. HTML is one of the few things that everyone in a web design firm will know.

Qcodo does a much better job of explaining itself and its philosophy than many other PHP frameworks. And from what I can tell, it seems to be well implemented. But it does not trust designers, and it writes too much HTML on it’s own. Consider the way it describes its code generation abilities:

Taking a quick look at the web front-end of codegen, you’ll see that only the top dozen or so lines (including comments) directly deal with the CodeGen object. Everything else past it is simply to paint a pretty HTML page to display the results.

“To paint a pretty HTML page”. Ah, yes. Well, I don’t think I’ll give it a try. I’ve a lot of PHP frameworks to test, and I’ve limited time, and this one sounds like it is taking too much power away from the designers.

If a programmer is also their own designer, then I can imagine why they’d want to write all the forms in PHP - it would save them some time. Peter Bowyer summed up that point of view with this post from 2003:

My current project is the biggest site I’ve had to design and build by myself. And in the process of planning the code I’ve realised why so many people have a framework they use. I’m having to do too much stuff here from scratch; code that should just plug in from existing projects. I’ve written a SQLBuilder library, polished up my own take on Fusebox, and am developing the FormProcessor library (the more I use it the more I realise why people do forms the “normal� - i.e. writing PHP to construct them - way: it’s such a pain writing these forms by hand. Dreamweaver really doesn’t speed up the generation much.

Right. But if the forms do need to be edited by a designer, perhaps using Dreamweaver, then it is better to have the form elements defined as pure HTML. If you are a lone, individual programmer you can do everything to suit your own taste, but when you’re working in a shop where several people work together on one site, then one needs a framework that maximizes how much the designers can do on their own.

Comments

The example you posted also has it’s flaws. Short tags are not portable and usually frowned at… so you’d have to add in another 3 characters (”php”) just to start a tag.. and then change the “=” to “echo”. Also, what does the “currentValue” function name mean to anyone looking at it out of context? Current value of what? It is a function now, not a method of an object… which means there is no state, and no member properties or methods… and that means it’s in the global namespace… which means the only way for that function to gain access to “id” or “user” is to have other global variables, and let’s hope there’s not another function called “currentValue” somewhere out there. Yikes! Anyway…

Your question, “Why would I want a framework that puts more work on me?”. You don’t, but Qcodo is also doing a lot of work for you, probably more work than you’d be doing without it. So really, it’s probably not making you do more work which is your question. But it all depends on your problem of course.

It’s all relative. We’re going to have to do *some* work :). It just depends on what kind; if you want control that is. Less need for control = less work. More need of control = more work, probably. It’s the glass half empty or half full thing. Do your designers need absolute control of every visual aspect? I wouldn’t think so. We need a nice middle ground, logical assumptions. But we’re talking PHP here and there isn’t a de facto standard framework. It’s tough no doubt, which is why you see hundreds of frameworks for PHP, everyone is trying to solve the same problems. A new one seems to popup everyday. I myself have written about 10 completely different ones. If you think about it, it’s completely impossible to NOT mix code with html in some way or another. Once you realize that, you just need to decide which is it? Having html being generated from code, or have the html/templates embed code?

- matt

Matt on 01-08-07 at 1:13 pm

Your question, “Why would I want a framework that puts more work on me?�. You don’t, but Qcodo is also doing a lot of work for you, probably more work than you’d be doing without it.

I don’t think of the decision as being between Qcodo or no framework, I think of the decision as being between a framework that puts more work on me, versus a framework that puts less work on me. While Qcodo simplifies some things it also complicates my life in some ways. I’d rather have a framework that that only simplifies things for me, without creating more work for me. I’d rather take the good ideas from Qcodo and leave behind the bad ones. The template system is one of the bad ones.

Do your designers need absolute control of every visual aspect? I wouldn’t think so.

My experience is otherwise. Your mileage may vary, of course, but for me, the less I control the HTML, the less work I do. The more work that the designers can do, the less work that I have to do. When I give up all control over the HTML, I minimize the work I do. When I try to gain control over the HTML (supposedly to automate production) then I create more work for myself because then the designers are constantly asking me to change the HTML in some way. When the designers are no longer able to control the HTML, they have to come to me and ask me to make the changes, and this increases my work.

You could, quite reasonably, ask whether the total amount of work was being increased or decreased by PHP functions that write some HTML. You could, quite reasonably, argue that even though the programmers work less when they’ve no control over the HTML, total work goes up because then the designers have to do more. You could make that argument, but in my experience the argument would be pointless. In the web design shops where I’ve worked, the single most common block on work-flow was the programmers. The single greatest inefficiency, that I’ve seen many times, is when a designer must wait on the programmer. I’ve seen designers sitting at their desks with nothing to do, because some programmer needs to tweak a layout class before the designer can proceed. At least for the places I’ve worked, productivity would have been boosted by leaving all HTML in the hands of the designers.

Lawrence Krubner on 01-08-07 at 7:11 pm

Matt asks: Do your designers need absolute control of every visual aspect?
I answer: Yes. Absolutely. How else can they do their job properly? Any methodology where the designers can’t design — and where the programmers can’t program — is fundamentally flawed.
Lawrence, have you tried Fusebox yet? It separates HTML from PHP code very nicely (unlike your Qcodo example). Or at least, its recommended design patterns do this. It’s unobtrusive enough as a framework that you don’t have to use its conventions — though they will make life much easier. As far as tradeoffs…it’s hard to think of any. Because of that unobtrusiveness, it generally doesn’t get in your way when you don’t want it to.

Marnen Laibow-Koser on 01-09-07 at 12:41 am

Marnen, I haven’t tried Fusebox yet, but thanks for suggesting it. I plan to use my weekends this month to test a bunch of PHP frameworks. I’ll write some reviews for this weblog.

Lawrence Krubner on 01-11-07 at 3:42 pm

The example you posted also has it’s flaws. Short tags are not portable and usually frowned at

I apologize about using short tags in my example. I never use short tags in my actual working code. I was simply being lazy when making that example.

Lawrence Krubner on 01-11-07 at 3:43 pm

OK. If you need any help with Fusebox, feel free to e-mail me at marnen AT marnen DOT org, or check out the forums. The documentation can be less clear than would be nice, and many of the tutorials are geared more towards ColdFusion. But the framework is very capable and the user community is great.

Marnen Laibow-Koser on 01-11-07 at 4:52 pm

I’m starting to wonder if the correct question is being asked. Maybe what is needed for some projects is not a perfect hole punched in the dam, but a bigger, more resolute wall: A method to build an html-only template (w/sample data available from the devs), and then “install” the template into the underlying system the developers have constructed.

If there are specs for a project area (for instance, a mail sign-up page), and the designer is working the app content space, the template designed by the designer is then adapted by the class to model the data correctly in that view. Unlike templates, however, everything would be in html…

I’m not sure exactly how it would work out, but I think it could be effective. You could also adapt a bbcode solution, as well… This is something I have thought long and hard about.

Jared Farrish on 01-27-07 at 8:14 pm

Jared, that sounds interesting, but what do you mean, precisely, when you write “the app content space”?

As to this, “he template designed by the designer is then adapted by the class to model the data correctly in that view”, we’ve been discussing something like that. It would be interesting to hear you elaborate.

Lawrence Krubner on 01-29-07 at 12:20 am

This is all kind’ve off the top of my head…

By app content space, I mean inside the content area that is being templated, be it the main menu, footer, an inline contact area, or whatever. App content space == editable region in the interface.

For instance, imagine you have a browser window open and you are logged into the page designer app. I could see an inline box representing the content space that is currently being edited (maybe a TinyFCK editor…), a “markup behind” toggle button to show/edit source, a css window with a refresh button, and a listing of all available resources for the current content area.

As the design progresses, the available resources are dragged from the resources view onto the page elements where appropriate to be used as place holders for the available data (as well as interpreted by the install_template process). If a piece of data is not available, but the designer feels it needs to be, maybe a request window is available to request it quickly and create a dummy holder of that value.

My problem, as a programmer-oriented web developer working alone, is giving non-enthusiast control to someone who understands not a lick of HTML (such as the owner of a website who wants or needs to edit their websites’ content). Putting together or finding a WYSIWYG solution for that is probably necessary for at least one project I have currently, but yet I need to find one that is not constrained by those limited boundaries, for my own editing needs. I need one with power features.

In other words, I need an interconnected small team HTML IDE…

If the idea is to have designers build templates, and programmers build the inner workings, then I would think a solution which took all script code out of the designers hands, as well as all markup out of the programmers, would be preferable to varying shades of (programming) grey.

Also, I’m sure you’ve heard of extreme programming. The flip side is to pair a programmer/designer and have them function as a in-tandem development unit, sitting next to each at a computer, with absolutely no boundaries. This is supposed to be a preferable solution to to rigid casting of roles, anyways, if you listen to the eXP guys.

Jared Farrish on 01-29-07 at 7:26 pm

Jared, I agree with you strongly when you write “I would think a solution which took all script code out of the designers hands, as well as all markup out of the programmers, would be preferable to varying shades of (programming) grey.” The framework that I’m envisioning allows no HTML in any PHP file. Rather, all HTML must be in HTML files which the PHP code may include. But all the HTML, without exception, is in the hands of the designer.

As to this:

The flip side is to pair a programmer/designer and have them function as a in-tandem development unit, sitting next to each at a computer, with absolutely no boundaries.

I worked right next to a designer last year, for 4 months, and we accomplished a great deal. Business consultants and programmers with long experience in the industry were impressed with what we accomplished during those 4 months. I’m convinced this is a very effective way to develop software.

My problem, as a programmer-oriented web developer working alone, is giving non-enthusiast control to someone who understands not a lick of HTML (such as the owner of a website who wants or needs to edit their websites’ content). Putting together or finding a WYSIWYG solution for that is probably necessary for at least one project I have currently, but yet I need to find one that is not constrained by those limited boundaries, for my own editing needs. I need one with power features.

I think I understand you. The client may need some mild WYSIWYG features, but you would need to control everything. That’s what I’m working toward as well. It should be easy for the designer to open up physical HTML files and edit them as they wish, but it should also be easy to give over small portions of the page to the client, to be edited in a WYSISYG environment. I’d like to see such a project move forward as an open source project. Done with intelligence and grace, it could be a powerful tool for web development.

Lawrence Krubner on 01-30-07 at 12:25 pm

The framework that I’m envisioning allows no HTML in any PHP file. Rather, all HTML must be in HTML files which the PHP code may include. But all the HTML, without exception, is in the hands of the designer.
Oh man. You have so got to try Fusebox. It’s sounding more like it’s the perfect framework for you: every time you bring up another criterion, you’re basically describing one more Fusebox feature.

Marnen Laibow-Koser on 01-31-07 at 1:45 am

Thanks, Marnen. I plan to use Fusebox for a small project over the next week. I’m going to be moving over to bluewallllc.com and there I plan to test several frameworks and post reviews. I plan to test Symfony, Fusebox, CodeIgnighter, and PHPCake. I’ll be posting reviews of all of them. We may develop our own framework, borrowing ideas from the others, or, if we like one framework very much, we will probably start contributing to it. And singing its praises so as to entice others to join up. I hope to either discover or develop a template system that exactly conforms to Darren’s idea of the ideal template system. That is a major goal for me.

Lawrence Krubner on 01-31-07 at 12:44 pm

Cool. I’ll try to keep up with your testing. I’m curious about other PHP frameworks as well.

BTW, Fusebox is very widely used by ColdFusion developers, but for some reason, not enough PHP programmers know about it.

Marnen Laibow-Koser on 01-31-07 at 1:02 pm

I have to disagree with your opinion on Qcodo putting more work on the developer. Qcodo encapsulates the creation and manipulation of html and javascript controls so that they can be easily reused, savings lots of time for designers/developers from repeatedly doing this (pseudo-code):

Is it really any more work for programmers to assign a QControl with a semantic ID and Class from the get go? Anytime you instantiate a new control just give it these attributes and the designer will never have to come asking for you to give one, and you kept control without adding work.

Brian Hazzard on 09-24-08 at 2:25 pm
Trackbacks


Leave a Reply