Claus Witt

Writing your own PHP Framework, should you do it?

While I worked at Wildside in Århus, Denmark, I wrote a MVC Framework for using in Typo3 extensions. The reason for this was that we were working on an application which required such a framework to structure the project to be as maintainable as possible without loosing performance. We started looking at different options, and none of them seemed right for the job, and most of them were either not usable in the context of Typo3, or not mature enough for production use.

When the project started there was a tight coupling to Typo3 since the application was pretty much just an extension to the website.

Since then a lot have changed, and I am now working directly for the client, who was a customer of my old company 9iA as well. The system is now more of a standalone web application and the requirements of the framework has changed many times since its first version in may last year.

The framework is, however still tight coupled to Typo3, but Typo3 is pretty much only used for templating and authentication.

In the last year and a half I have worked with a lot of php frameworks – saying that I have used all of them is off course an exaggeration, but I have been using most of the top ones in some way or the other. And not one of them work in exactly the way I would want them to.

Now I am wondering wether to rewrite my mvc framework to be standalone. It would not demand more than 30-50 hours of work to do that, and on top of that be able to integrate Zend Frameworks Components and an existing ORM like perhaps Doctrine.

The other possibility is to rewrite the application to use an existing well tested framework. If Flow3 had been ready for production (and working in php 5.2.x) that would probably had been the case. But now I’m just not sure.

No mather what we decide to do, the current version will go live without any kind of rewrite. But the learning experience from writing your own PHP MVC Framework might be nice to gain, at some point – even though most of it is written allready.

What would you do? And if you would use an existing framework – which one would you recommend?

Btw, no mather what we choose to do, the framework will be released to the public as soon as all bugs that I have found have been fixed, and some basic documentation have been written.

I found an article about 10 principles of the php masters. There is an interesting thing about the list however. Number 7 and 8 on the list will be impossible to follow at the same time for example.

The list is as follows:

• Use PHP Only When You Need it – Rasmus Lerdorf
• Use Many Tables With PHP and MYSQL for Scalability – Matt Mullenweg
• Never, ever trust your users – Dave Child
• Invest in PHP Caching – Ben Balbo
• Speed up PHP Development with an IDE, Templates and Snippets – Chad Kieffer
• Make Better Use of PHP’s Filter Functions – Joey Sochacki
• Use a PHP Framework – Josh Sharp
• Don’t use a PHP Framework – Rasmus Lerdorf
• Use Batch Processing – Jack D. Herrington
• Turn on Error Reporting Immediately – David Cummings

Take a look at the original post to get an explanation of each of the statements.

As I have talked about several times, I am planning several saas projects in the future. The amount of ideas vastly surpasses the amount of time available to create these projects, but one of the things I can do until I (and possibly a small team of other people) decide to actually do any concrete work is to collect some methods of doing things that all apps will have to have. One of these are SSO. We would definitely like all our applications to share some kind of login information, and probably other information as well, when the time is right. Applications should in my opinion be as integrated as possible with shared api conventions, shared user-schemes and possibly even shared design and workflow elements. I personally hate it when a company releases several webapplications and I nothing in application A looks/seems/works like anything in application B. It should be – at least in my head – simple to do some kind of shared vision of the app’s.

A long text for post a link. But here goes. I found a post about how to create SSO for webapplications. I have earlier looked at CAS for SSO and that looks like a good implementation. But I guess some experimentation is in order. More on this later…

While looking at a post about using memcache for a simple message queue, which by the way sounds very interesting in its own right. I once again found a link to the MemcacheDB project. They have made memcache persistent. It is some sort of and intermediate between regular memcached and a database. I can think of several scenarios where memcachedb would be useful. One that comes to mind is persistent storage of user- og and settings- objects in the system that I am currently working on, for Voicearchive.com.

I haven’t tried it (yet), and it’s probably not something that a lot of people would find that interesting/useful. But I just found an open source ASP 2 PHP compiler, which will take any asp page (written in vbscript) and create a corresponding php page. Sounds fun. If only I had some of my asp based projects from 2001/2002 lying around somewhere… But that would require me to go back in time, and tell my self to make backups.

For a while we have worked on making our website at work more responsive. We have a lot of visitors looking for voice over talents, and since we primarily do business across the web, mainly through our website, it is important to us that it is as responsive as possible. Apart from the classic guidelines you always hear when running a website, we have experimented with a hacked version of Typo3 to enable the use of Memcached as a page cache.

And as I suspected, performance was highly impacted by this. Through all our optimizations we have reduced the load time of the page to an absolut minimal. Next we will look at ways to reduce the amount of javascript needed for some of our features.