XHTML.net

1. Home
2. PHP: Hypertext Preprocessor

The use of the middleware in Pluf

The 2007-02-21 at 15:12 by Loïc d'Anterroches filed under PHP: Hypertext Preprocessor.

The best technical choice I made for the structure of Pluf was to follow the lead of the Django Project. I created Pluf because I really needed to have the Django speed of development on systems where using Python was not an option. This was not an option because I had to implement a solution to be then maintained by people not having the right knowledge. I learnt the hard way in the past that the best technical solution is also the one that can be handled by the people in house.

Ok, back to the topic, what I really enjoyed with Django was that the data are nicely encapsulated with basically:

• A request object representing the query with GET/POST data.
• A dispatcher that will call a given view function based on the request URI.
• A response object created in the view function and sent back to the client.

On top of that you have middleware. Middleware are men in the middle, they take a request object and modify it before giving it to the view, or, take a response object and modify it before giving it back to the client.

At the moment, on the main conference website, I am using 2 middleware, a maintenance middleware and a session middleware.

The session middleware handles session, nothing really new in it and the maintenance middleware is a really small but practical middleware. What it does is that if a MAINTENANCE file is found at a given place on the server, it automatically intercept the request and returns a page telling that the server is in maintenance. Basically, when I want to perform a complex upgrade which cannot be performed fully live, I just go in the right folder and touch MAINTENANCE, perform the upgrade and then remove the file.

But what is really interesting is the ability to modify the response after the view generated it. I have upgraded the Tidy middleware to modify the </body> tag of the page and append just before the log of the errors when running Tidy against the content of the page. It means that now, I do not have to think when the page is not valid, I have the error messages right away! I just take a look at the source of the page, find the error, fix the code, reload the page. It is fast and fun, no need to painfully submit your code to a validator or copy/paste the code to validate it.

When developing, I am using a Debug middleware to display the peak memory usage of the page, the execution time and the database queries. It is very practical to spot the weaknesses in the code. As you can see in the following screenshot, the peak memory is provided using the Xdebug xdebug_peak_memory_usage function and when you click on the DB query # link, you can see all the queries (it is just a little javascript to toggle the visibility style of the <div> containing the queries).

Something I often miss in organisations, is that we tend to act a lot based on feelings and not based on factual data. Very often it is easy to gather the data to support your decisions, but people are not doing it. So enjoy the Pluf Middleware to know what is going on in your code and improve based on real data.

---