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.

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.

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…

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.

This time around, however, I found what I was looking for. I found an article about PHP and jQuery upload progress bar. In this article I learned about the PECL extension uploadprogress. I began trying to make this solution work.

First thing, was that I found the extension did not work as I wanted. After a while I found that installing newest version, required installing it via “pecl install channel://pecl.php.net/uploadprogress-0.9.2″ – which gave me the latest beta release of the extension. Now it returned the correct information when I uploaded a file.

The solution consists of 5 parts.

1. The Pecl extension
2. The form
3. The progressbar widget
4. The javascript
5. and the controller which sends the data from uploadprogress as json to the client

After the installation was managed, I changed the form to have the required hidden UPLOAD_IDENTIFIER value included.

The value of the field is set when the dialogbox containing the upload form is revealed, and saved in a variable, that can be used when the script needs to poll for the result.

lastFileProgressKey = guid();
console.log(lastFileProgressKey);
dojo.byId('addFileProgressKey').value = lastFileProgressKey;
dijit.byId('addFileDialog').show();

The guid function is just a simple function which generates a guid-like random string. The value is then set to the form, and the dialog is revealed.

When the upload button on the form is pressed it calls a event handler which handles the actual upload. Before the upload is started however the following function is called.

startUploadCheck(lastFileProgressKey);

These function do the actual work.

function updateProgressBar(response) {
	if(response) {
		totalBytes = parseInt(response.bytes_total);
		uploadedBytes = parseInt(response.bytes_uploaded);
		percentage = Math.floor(100 * uploadedBytes/ totalBytes);
		uploadProgressBar.update({ progress: percentage+'%'});
		if(lastUploadId!='') {
			setTimeout("checkUpload()", 1000);
		}
	} else {
		if(lastUploadId!='') {
			setTimeout("checkUpload()", 1000);
		}
	}
}

function checkUpload() {
	dojo.xhrGet( {
		url :'/uploadprogress/check?uploadid='+lastUploadId,
		handleAs: 'json',
		preventCache: true,
		load: updateProgressBar,
		error: function(data) {
			if(lastUploadId!='') {
				setTimeout("checkUpload()", 1000);
			}
		}
	});
}

function startUploadCheck(uploadid) {
	dijit.byId('uploadProgressDialog').show();
	lastUploadId = uploadid;
	checkUpload( uploadid );
}

function hideProgressDialog() {
	lastUploadId = '';
	dijit.byId('uploadProgressDialog').hide();
}

The dojo widget used is the ProgressBar.

The controller is the simplest part of the equation.

public function check() {
    $formUploadId = $this->request['uploadid'];
    return json_encode(uploadprogress_get_info($formUploadId));
}

All the legwork is done by uploadprogress_get_info, which then is passed through json_encode.