In a quick post to his site Sameer Borate looks more in-depth at how MVC routers work to translate the incoming request and point it to the right code for handling.

A MVC Router class or a Dispatcher inspects the URL of an HTTP request and attempts to match individual URL components to a Controller and a method defined in that controller, passing along any arguments to the method defined.

He provides the code for a simple example, matching the path directly from $_SERVER['PATH_INFO'] to a key name in a set of routes. Routes are added to the list via an add_routes method and are only matched directly. This is the most basic version of a router with many other frameworks stacking features on top including wildcard matching, optional parameters and regular expression matching.

Lukas Smith is looking for feedback about a question that's been in his mind a lot lately - can the handling of query parameters be made better for the Symfony2 framework (and even easier to use).

Obviously you can already access query parameters today already but it could be easier. Essentially what I want is a way for developers to easily configure what query parameters they expect and what values they expect. This is useful for several things like easier reading and validating of query parameters, self documenting API both for API docs for humans but also for machines.

He's asking for feedback and ideas from the community on a proposed solution that could make things more flexible. He also briefly mentions the route matching and how qurey parameters could cause them not to match:

For one I don't think that a mismatch on a route requirement of a query parameter cause the route to not match. However then it can quickly become confusing for the end user or it would require adding more and more syntax to handle all the different cases.

Regular expressions have always been something that have mystified developers, even those seasoned ones looking to match the most complicated data. If you're just venturing into the world of regex, PHPMaster.com has a good guide to help you wade through some of the basics.

It makes all the sense of ancient Egyptian hieroglyphics to you, although those little pictures at least look like they have meaning. But this… this looks like gibberish. What does it mean? [...] When you’re looking to go beyond straight text matches, like finding "stud" in "Mustard" (which would fail btw), and you need a way to "explain" what you’re looking for because each instance may be different, you’ve come to need Regular Expressions, affectionately called regex.

The include a (somewhat) complicated example regex string and break it down chunk by chunk - groupings, character sets, multiple matching, delimiters and more (the pattern matches valid email addresses). They show how to use it in PHP with preg_match, preg_replace and preg_match_all for different situations.

In a quick post to hos blog today Stoimen Popov points out a handy feature of the preg_match function in PHP (in PHP 5.2.2 and higher) to be able to name the results of the regular expression match.

In PHP 5.2.2+ you can name the sub patterns returned from preg_match with a specific syntax. [...] This is extremely helpful, when dealing with long patterns. [...] Although it may look difficult to maintain, now you can simply name the sub patterns of preg_match and to call them with their associative array keys. This is more clear when writing code and it's definitely more maintainable.

The key is to use a special syntax as a part of the expression's pattern. This replaces the numeric keys of the matches with values you define, making it simpler to use the results (instead of having to work with numbers that don't match much of anything). Code and expression examples are included.

Jordi Boggiano had the "pleasure" of discovering a small quirk with PHP's glob function in an application he was working on - watch out for directories that contain square braces, they won't return in the results!

Working on some personal project that lists a bunch of stuff on my hard drive, I found out that directories that contain square brackets (those []) don't return any results for the simple reason that glob reads [stuff] as a character class, just like in regular expressions. When you know it it makes perfect sense, but when you don't, the documentation is really not so helpful. Of course it mentions libc's glob() and unix shells, but not everyone knows what that implies at first glance.

He tried a few things to get around the bug (including escaping the brackets in the directories) but ended up writing a function (glob_quote) to handle the escaping of all of the meta-characters glob might need to escape to return all of the files and folders correctly.

On the echolibre blog J.D. has made a new post looking at Zend Framework routing and how you can customize it to get the user where they need to go.

I wanted to write a post that shows a few different ways to customise Zend Frameworks routing when you’re using their MVC implementation. Most of this is covered in the documentation, but it can be a little difficult to dig out.

He starts with the normal routing setup (the standard /module/controller/action and /controller/action setups) and moves on to the "magic" - a way to have a standard "framework URL" without having to include an action. He sets up a route with a wildcard to catch anything for that controller and passes it off to a custom router that goes through the request values and returns the values as though they were formatted normally in the URL.

Gareth Heyes has posted another challenge to his blog - this time it involves using a regular expression to convert the inputted string into the output he's given.

After the success of my “a bit of fun” challenge, a few people asked for some more challenges. So I was answering a question on a mailing list that I'm a member of and I thought it would be a good topic for a little challenge and help sharpen everyone's regular expression skills.

This time, his challenge involves taking the input, rail start/end locations from an array and, via the PHP script given (no regular expression in it, of course) make the output, a sort of JSON formatted message. It's already been answered, but if you want to, try it yourself first then read the answer below the post.

Gareth Heyes has posted another challenge to his blog - this time it involves using a regular expression to convert the inputted string into the output he's given.

After the success of my “a bit of fun” challenge, a few people asked for some more challenges. So I was answering a question on a mailing list that I'm a member of and I thought it would be a good topic for a little challenge and help sharpen everyone's regular expression skills.

This time, his challenge involves taking the input, rail start/end locations from an array and, via the PHP script given (no regular expression in it, of course) make the output, a sort of JSON formatted message. It's already been answered, but if you want to, try it yourself first then read the answer below the post.

On the PHP Security Log today, Stefan Esser points out some holes in most of the filters using preg_match that he's seen in examples and the like all around the web. Some of these things could cause issues that could breach the security of your application.

During the last week I was performing some audits and like so often it contained preg_match() filters that were not correct. Most PHP developers use ^ and $ within their regular expressions without actually reading the documentation about what they really achieve.

However the problem is, that the author of such a regular expression did not correctly read the documentation and mistakes the $ character for the definitive end of the subject.

According to Stefan, the actual documentation for the $ character in a regular expression isn't quite used that way. It does mean "the end" of the match but it can also match against a newline as well. His suggestions? Use the /D modifier on the end of the expression to match the real "the end" and not how it might match otherwise.

On the PHP Security Log today, Stefan Esser points out some holes in most of the filters using preg_match that he's seen in examples and the like all around the web. Some of these things could cause issues that could breach the security of your application.

During the last week I was performing some audits and like so often it contained preg_match() filters that were not correct. Most PHP developers use ^ and $ within their regular expressions without actually reading the documentation about what they really achieve.

However the problem is, that the author of such a regular expression did not correctly read the documentation and mistakes the $ character for the definitive end of the subject.

According to Stefan, the actual documentation for the $ character in a regular expression isn't quite used that way. It does mean "the end" of the match but it can also match against a newline as well. His suggestions? Use the /D modifier on the end of the expression to match the real "the end" and not how it might match otherwise.