It would we great if routes.cfm had the ability to add an external URL attribute and possible http status code attribute to enable routes.cfm to be use for routing legacy site urls. This would allow a cleaner overall approach as opposed to using web server redirects for some routing and ColdBox for other routing. I see that some might say that since its routing to an external URL then it shouldn't hit the framework, however I feel this would be a beneficial addition to routes.cfm as it provides a common interface for routing. Thoughts?
I like your analogy of the routes.cfm being an incoming traffic cop and that’s precisely why I think it could be used for to perform this sort of requirement because execution doesnt have to continue down to the handler. Let’s say I have upwards of 20 legacy URL’s that i want to remap and some of them are now being redirected to another site in a different domain, it doesn’t make sense to allow the request to go down into a handler. I’d rather catch it at the routes level and force the redirect higher in the request stack.
And why would it be a good idea to add extra overhead of running code just to do a redirect?
Personally I would say these sort of things should be handled by your rewrite rules, and not processed by ColdBox then doing another redirect is adding extra time to loading the page for what benefit?
Lucky for me I have full control of my servers, but consider a scenario where the hosting environment does not provide access to IIS or Apache and you have to go through a support queue to have rewrite rules added. this would be a hassle.
I’m mainly just looking for a common interface for routing functionality. I develop on a Mac using apache, yet our servers are Windows, so having to jump around in different webserver configs to do something that I could achieve in one line of code, which provides a common routing interface and which has very little overhead to the application seems silly.
I think part of the problem with “traditional” hosting scenarios is that as developers we try to always follow the traditional approach - i.e redirects should be handled at the web server level because it doesn’t belong in the framework. This ultimately leads to so many different layers of technology management to sometimes do something really simple. Now fast forward to the age of newer frameworks like Node.JS which is purely javascript, on the client and the server. Mostly everything is done within JS which makes it extremely powerful, flexible and easy to use. And Node.JS is essentially a framework. I’m sure Node developers struggle with the same approaches of where they should put rewrite rules, and I bet it’s done at both the server and app level
This is just my opinion and I respect yours as well.
That was only one part of my argument. The main point was about the simplicity of frameworks and not needing to deal with multiple layers of the stack to do simple things. That’s the way newer frameworks are heading.
I tend to agree with Nolan on this one. I actually had a ticket somewhere to add this where you can map incoming patterns to redirects either full or relative.
Thanks Aaron. Looks like that could work as well. I’ll let Luis make the call on whether he thinks my proposed approach makes sense as addition to the addRoute() call. If it were added it would be nicely encapsulated. Cheers,