Josh Sharp - web application development.

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

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