Josh Sharp design and development. Web pages with purpose.

I've just been browsing the PHP6 meeting minutes to see if anything exciting is coming up in the next release. There are a couple of handy things which I might post about soon, but in the meantime this useful code snippet caught my eye. I wasn't aware you could handle errors yourself in PHP5, but it seems it is possible to do so. The following catches all errors of level E_NOTICE and throws an exception instead. Pretty handy if you already use Exceptions for your own errors — now you can decide what to do with parser errors, instead of being forced into displaying them or just ignoring them.

The code:

<?php
	function error_handler($errorType, $message){
    	    if ($errorType == E_NOTICE) {
        	        throw new Exception( $message, $errorType);
        	}
	}

	set_error_handler('error_handler');
?>

For those of you who aren't aware, Apache provides a very nifty module called mod_rewrite which (can you guess?) lets you rewrite URLs, with or without the end-client knowing. As I've mentioned before, this can be pretty handy. No longer must your URLs look like domain.com/folder/subfolder/file.php?some_id=23. Instead you can present your users with pretty URLs like domain.com/area/action/this_is_a_unique_identifier, and anything along those lines.

There are two main reasons why you'd want to do this:

• Accessibility for users: your users don't need to remember long GET parameters, or file extensions for that matter. URLs can become more relevant to the content and to the user.
• Accessibility for search engines: yes, this will help you quite a lot with The Google. You now have a far bigger chance to put your relevant keywords into the URL, which is one of the places they count the most.

So let's have a look at how you'd do this.

Keep reading

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.

Keep reading

Now, if you're an open-source developer, you probably break into a sweat whenever working with Microsoft products is mentioned. Apache will always beat IIS and MySQL (or PostgreSQL) will reign supreme over SQL Server, despite those naysayers who worship at the temple of Steve Ballmer (I hear they chant "developers, developers, developers" and dance in religious ecstasy). And so it is with me. I knew that SQL Server had all those extras like stored procedures, user-defined functions and views — which MySQL didn't until recently — but I preferred the non-evil side of the force.

Turns out MySQL offers some little extras after all. Little things like the LIMIT clause, which allows you to define a range of results to be returned. This function is absolutely invaluable in paging data, but... in versions of SQL Server older than 2005, there's just nothing similar. The closest is the TOP clause, which returns the first X amount of rows, but does not allow you to specify a starting index.

What follows is a journey of strength and courage, of overcoming adversity, of sticking with SQL Server even when all seems hopeless. This is the story of attempting to page data returned from SQL Server 2000.

Keep reading

There's a reason why PHP is growing rapidly as a server-side scripting language — it's very easy to pick up. Many functions are included without needing any sort of namespace importing, and you don't even have to write OO code if you don't want to. Variables are weakly typed and the syntax is fairly familiar.

But PHP's ease of use is also its downfall. Because there are less restrictions on the structure of the code you write, it's much easier to write bad code. But there is a solution: use a framework.

PHP frameworks like CakePHP, CodeIgniter and the Zend Framework (which I wasn't too taken with) provide a solid structure for your code whilst also offering some extra functionality that would be much harder to replicate on its own. It's important to note, too, the frameworks mentioned follow the MVC pattern, which is fairly common and what I'll talk about below — some of these benefits will apply to other patterns as well, but not all.

Of course, if you're not taken with any of the packages above you can also write your own framework, which I've done and will talk about in the next few posts. But for now, let's have a look at the common benefits of a framework.

Keep reading

A very nifty feature of PHP 5 is the ability to create dynamic or "magical" functions. These functions do not explicitly exist per se, but are defined through the use of a __call() function. For example, if I call $obj->getSomeData() and this method is not defined, that's where __call() steps in.

I use this in my framework as a basis for getters and setters on my data objects. A data object is really just a big associative array with getters and setters exposed, which can either be magical or can be overridden. This has several advantages – hiding of the actual array variable, ease of use (as the functions are magical) and an easy way to override these functions if extra functionality is required.

Keep reading

Zend are the company behind the development of PHP itself, as well as a lot of professional PHP tools, such as the Zend Optimiser, which optimises and caches code (as the name implies). So it was with a bit of enthusiasm that I read the news that Zend Framework 1.0.0 had been released. I've been looking around for a decent PHP framework for a while now, and eventually settled on writing one myself. There are pros and cons to each way of working – with your own code, you can leave out the irrelevant parts, and write something that makes sense to you and operates as you wish. But on the flip side, you can't beat the polish and sheer size of a community-built framework.

Zend Framework promises:

• A modular structure – only use what you need
• A full MVC framework
• considerable extensibility
• A sprawling mass of modules covering everything from authentication to a built in Amazon Services API.

Keep reading