Symphony.

I’ve been following the latest changes related to Symphony 2.2, and noticed that Symphony does not really have a solid route system like in other frameworks. I think this is something that we’ve to rethink for Symphony 3.

Symphony stores extra routes provided by extensions (core and third-party) in htaccess. In my opinion, this approach is inflexible because it force developers to parse this file and write some rules there.

This is a good reason to think and develop some kind of Routes API.

I see many benefits from doing this.

• Remove dependencies of any server software vendor.
• Support other servers like Nginx.
• No more headaches with invalid rules.

Why we can’t leave the routing job to Symphony and use a simplified version of htaccess? (e.g. pastie.org/1509022)

Just my 2 cents!

+1. I really like the idea of being able separate routes from resources. The URL router extension does decent job, but it could be much more robust and flexible.

Yep I agree about an easier way of managing routing.

I have previously suggested Symphony provides an API for modifying the .htaccess file itself which works just like the Configuration class in that an extension can maintain its own namespaced section within the file.

My biggest concern is performance. Routing every request through Symphony directly could be costly. Think of how the JIT image manipulation extension works now. A request namespaces with /image/ is picked up in .htaccess and routed to the extensions image.php, bypassing Symphony entirely. This is a good thing. However if every request is mapped to Symphony (and indeed mapped to PHP), then Symphony has to be instantiated for every request. If extensions can tap into routing then it may be that Symphony needs to load extensions at runtime. This could be a costly routine to establish a route.

However, Symphony 3 uses flat XML for delegate subscriptions, so could use flat XML for routing subscriptions, so I would hope this routine would be super-quick.

For Symphony 2, I actually prefer your method Nick, With an API like the configuration, like you say, it’s much more efficient resource handling.

Keeping as much routing logic deferred to Apache as much as possible is ideal for reasons Nick described above. The performance difference between PHP v.s. Apache routing are many folds.

We have thought of an routing extension that provides a conventional Symphony interface (table entries + edit form) that maps individual routing rules as entries to an XML configuration, which is then responsible for converting it to htaccess, much like what Nick has suggested.