Back to the blog
Recent Posts
-
Apr 27
Thoughts on Android and the HTC Dream
-
Feb 26
Announcing Twitterscribe: archive your tweets
-
Jan 01
Adventures in PHP interfaces
-
Oct 17
How do you mockup websites?
-
Oct 09
Something's not right with Android's UI
-
Oct 06
My lance is free
Most Popular Posts
-
Why you should be using a framework
-
Perhaps the world doesn't need another framework
-
Rewriting URLs with Apache's mod_rewrite and PHP
-
Five easy things that make you a better web developer
About the Blog

I'm a web application developer in Melbourne, Australia. If you find anything useful, leave me a comment, and if you need web design, development, or accessibility and usability consulting, contact me! Cheers.
Twitter: joshsharp
Perhaps the world doesn't need another framework
Thursday 25 Oct, 2007 09:02 PM

Well after the last post on this topic, it seems like frameworks are one of those topics that divide the PHP community. You either love them or you think developers who use them are weak, girly-men who probably can't open jars without help and only use frameworks because they don't understand how to write good, simple code. Me, I am that girly-man — but I do know how to write good code, thankyouverymuch.
The thing about writing a framework yourself is that it gives you the best possible understanding of how it works. There is not one part of that framework that you don't have to really think about as you code. "Do I really need this?", you think, or perhaps more likely, "I don't understand how that works — I'll leave it out".
While I coded I learnt about URL rewriting, dynamic methods, abstract classes (well, how to use them in PHP anyway) and a bit about form state persistence and the like. And the result is that I know exactly how to put my framework to best use for whatever the project may be. It may not be a good framework, but it's mine.
But...
But there's always a flip side. A comment by Joshua May got me thinking — he mentions that he had to work with an in-house framework at his last job, the author of which had previously left the company. With no documentation, he was "in the deep end".
And that's just what would happen if I left my current employer. A good number of products (including OurIntranet) are developed on my framework, meaning the company would be left to support something lacking formal documentation (though there is an API).
And really, that's not good enough.
Joshua is right. We need to stop reinventing the wheel. Community-supported frameworks will invariably beat their homegrown cousins. Sticking with the big boys is the easiest course of action for everyone: you get a stable, mature framework on which to build, and the people who have to support your work get documentation and a community that can help. A bit of research reveals that there are at least a dozen frameworks out there which are actively being maintained, and have various levels of community support. That's a lot of choice really. Surely one of them will fit your coding style and your needs.
Although..
If you still want to write a framework, it can still be a good idea and it you willl definitely emerge a better programmer. But if others may need to use it after you, make sure it's well documented. (Of course, if you're freelance, you're off the hook — the only person who has to support your code is you.)
And me? I still think there's no way I could go without a framework now. Madness!
But right now, I guess I had better get into that documentation.
Comments
i know the view should only really contain echo/print and foreach loops.
the model should contain functions to hand your SQL statements.
and where i get stuck in the implimenting the controller properly.
i basically have a massive. if $_GET = $this do $this. if $_POST = $that do $that.
how do you implement the controller properly. im aware there is more than one way. If you find the time to do a tiny example that would be great.
the man who invented PHP (ramsus something) did this with code examples procedurally which is prefect for a small example but he put in all this ajax stuff which distracts from what i needed to take out of it.
do you thing perhaps you could procedurally whip up a bit of a hello world type example. maby one that is compatable with using you mod_rewrite friendly url method.

I think as you mentioned it all depends on the type and scale of the project you are working on.. For rapid projects with tight deadlines naturally the advantages of scaffolding and magic methods are an advantage, but in large scale projects it ends up being clutter that you end up inevitably struggle against.
That said, any simple CRUD application (such as blogs, simple CMS's, etc) should ideally be done in one of the pre-existing frameworks like cake and they save you a *lot* of time especially in the analysis and design stages (code design, not graphic design).
If on the other hand your writing a commercial web service application (i.e a new CRM/Financials system?) thats going to take your team more than a few months to "slap together" allocate some time at the beginning to analyse and design a framework that addresses exactly what the system requires, and be better off for it down the track; remember - the main difference for web apps is that they are distributed and so performance and scalability is crucial if its commercial. Just make sure you document, document, document unless you want to support the system for the rest of its lifetime...