Django, Rails Routing...Point?
Asked Answered
B

6

6

I'm a student of web development (and college), so my apologies if this comes off sounding naive and offensive, I certainly don't mean it that way. My experience has been with PHP and with a smallish project on the horizon (a glorified shift calendar) I hoped to learn one of the higher level frameworks to ease the code burden. So far, I looked at CakePHP Symfony Django and Rails.

With PHP, the URLs mapped very simply to the files, and it "just worked". It was quick for the server, and intuitive. But with all of these frameworks, there is this inclination to "pretty up" the URLs by making them map to different functions and route the parameters to different variables in different files.

"The Rails Way" book that I'm reading admits that this is dog slow and is the cause of most performance pains on largish projects. My question is "why have it in the first place?"? Is there a specific point in the url-maps-to-a-file paradigm (or mod_rewrite to a single file) that necessitates regexes and complicated routing schemes? Am I missing out on something by not using them?

Thanks in advance!

Blouson answered 31/12, 2008 at 7:34 Comment(0)
N
6
  • URLs should be easy to remember and say. And the user should know what to expect when she see that URL. Mapping URL directly to file doesn't always allow that.
  • You might want to use diffrent URLs for the same, or at least similar, information displayed. If your server forces you to use 1 url <-> 1 file mapping, you need to create additional files with all their function being to redirect to other file. Or you use stuff like mod_rewrite which isn't easier then Rails' url mappings.
  • In one of my applications I use URL that looks like http://www.example.com/username/some additional stuff/. This can be also made with mod_rewrite, but at least for me it's easier to configure urls in django project then in every apache instance I run application at.

just my 2 cents...

Noreen answered 31/12, 2008 at 7:49 Comment(0)
S
6

Most of it has already been covered, but nobody has mentioned SEO yet. Google puts alot of weight on the URL itself, if that url is widgets.com/browse.php?17, that is not very SEO friendly. If your URL is widgets.com/products/buttons/ that will have a positive impact on your page rank for buttons

Scenario answered 2/1, 2009 at 12:52 Comment(0)
D
3

Storing application code in the document tree of the web server is a security concern.

  • a misconfiguration might accidentally reveal source code to visitors
  • files injected through a security vulnerability are immediately executable by HTTP requests
  • backup files (created e.g. by text editors) may reveal code or be executable in case of misconfiguration
  • old files which the administrator has failed to delete can reveal unintended functionality
  • requests to library files must be explicitly denied
  • URLs reveal implementation details (which language/framework was used)

Note that all of the above are not a problem as long as other things don't go wrong (and some of these mistakes would be serious even alone). But something always goes wrong, and extra lines of defense are good to have.

Deepseated answered 2/1, 2009 at 12:33 Comment(0)
S
2

Django URLs are also very customizable. With PHP frameworks like Code Igniter (I'm not sure about Rails) your forced into the /class/method/extra/ URL structure. While this may be good for small projects and apps, as soon as you try and make it larger/more dynamic you run into problems and have to rewrite some of the framework code to handle it.

Scientistic answered 1/1, 2009 at 3:8 Comment(0)
K
0

Also, routers are like mod_rewrite, but much more flexible. They are not regular expression-bound, and thus, have more options for different types of routes.

Kurtz answered 31/12, 2008 at 7:53 Comment(0)
D
0

Depends on how big your application is. We've got a fairly large app (50+ models) and it isn't causing us any problems. When it does, we'll worry about it then.

Dilettante answered 31/12, 2008 at 10:42 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.