Re: Opinion sought on example.com/username
It's always a bad idea to mix different types of urls without having clearly defined separate prefixes for each. Basically it's like having a global namespace, and even worse is that you don't get ambiguity errors in case of overlaps, you get one url superseding the other (this also applies to static files hijacking a request with the same url, which I guess both rails and pylons do by default, and then for each request you actually have to check if a file with that name exists and only if not then dispatch the rails/pylons action == that is really bad programming, performance wise and logic wise). it's like having the home directories not be under /home so if you get a user named etc you r screw3d !!! On Dec 20, 1:07 pm, Mike Orr sluggos...@gmail.com wrote: On Sat, Dec 20, 2008 at 11:42 AM, Wichert Akkerman wich...@wiggy.net wrote: Previously ED209 wrote: I'm planning on moving my users' profile pages to: example.com/:username but there has been some discussion amongst fellow developers that this might cause problems. I would have this route and subsequent routes as the last ones defined in my array of routes defenitions so any static routes would be matched first. What if at some point in the future you need a new static route and a user already registered with that username? Well, that is where the Rails helpers' convention of /images, /stylesheets, and /javascripts makes some sense, because that way you only have to reserve a few prefixes. You could also reserve 'static' in case something else comes along that doesn't fit into these categories. -- Mike Orr sluggos...@gmail.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Opinion sought on example.com/username
On Sat, Dec 27, 2008 at 12:33 AM, Tycon adie...@gmail.com wrote: It's always a bad idea to mix different types of urls without having clearly defined separate prefixes for each. Basically it's like having a global namespace, and even worse is that you don't get ambiguity errors in case of overlaps, you get one url superseding the other (this also applies to static files hijacking a request with the same url, which I guess both rails and pylons do by default, and then for each request you actually have to check if a file with that name exists and only if not then dispatch the rails/pylons action == that is really bad programming, performance wise and logic wise). it's like having the home directories not be under /home so if you get a user named etc you r screw3d !!! Pylons, or rather the StaticURLParser app in middleware.py, has the first chance at the URL and looks for a file in the public directory. If it can't find it, it returns an HTTP 404 and it then tries the Pylons application. (This is all done by the Cascade application in middleware.py.) Pylons could set up a prefix for all static files, but then people would complain they want another prefix or they need multiple directories. Plus, certain files like /robots.txt and /favicon.ico can't have a prefix. So Pylons punts and lets you put your static files under any URL. It's up to the programmer to choose one or a few easy-to-remember directories to put under it. I had an application in another framework (Quixote) where you had to set up static file handling manually. I put them all under a /static prefix. Then I had to set up two more handlers for robots and favicon, and then another for a directory of user-uploaded images. But I put all the help files under static because they were pregenerated HTML made by RoboHelp. When I converted the application to Pylons, I got rid of the /static prefix and was happier. -- Mike Orr sluggos...@gmail.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Opinion sought on example.com/username
I use /static for all my static file, except maybe robots and favicon which cant be moved. As for StaticURLParser, using that as the first choice in the Cascade is wasteful cause it means pylons will do a file lookup for every request (bad performance) in addition to the fact that filenames may hijack pylons controller mapped routes (bad design calling for bugs). You can (and should) get rid of StaticURLParser and the Cascade if your web server is serving the static files (with a /static url prefix), or at least move StaticURLParser to the second choice in the Cascade when accessing the app directly from Paster http server (without a separate web server). On Dec 27, 12:54 am, Mike Orr sluggos...@gmail.com wrote: On Sat, Dec 27, 2008 at 12:33 AM, Tycon adie...@gmail.com wrote: It's always a bad idea to mix different types of urls without having clearly defined separate prefixes for each. Basically it's like having a global namespace, and even worse is that you don't get ambiguity errors in case of overlaps, you get one url superseding the other (this also applies to static files hijacking a request with the same url, which I guess both rails and pylons do by default, and then for each request you actually have to check if a file with that name exists and only if not then dispatch the rails/pylons action == that is really bad programming, performance wise and logic wise). it's like having the home directories not be under /home so if you get a user named etc you r screw3d !!! Pylons, or rather the StaticURLParser app in middleware.py, has the first chance at the URL and looks for a file in the public directory. If it can't find it, it returns an HTTP 404 and it then tries the Pylons application. (This is all done by the Cascade application in middleware.py.) Pylons could set up a prefix for all static files, but then people would complain they want another prefix or they need multiple directories. Plus, certain files like /robots.txt and /favicon.ico can't have a prefix. So Pylons punts and lets you put your static files under any URL. It's up to the programmer to choose one or a few easy-to-remember directories to put under it. I had an application in another framework (Quixote) where you had to set up static file handling manually. I put them all under a /static prefix. Then I had to set up two more handlers for robots and favicon, and then another for a directory of user-uploaded images. But I put all the help files under static because they were pregenerated HTML made by RoboHelp. When I converted the application to Pylons, I got rid of the /static prefix and was happier. -- Mike Orr sluggos...@gmail.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Opinion sought on example.com/username
On Sat, Dec 27, 2008 at 1:26 PM, Tycon adie...@gmail.com wrote: I use /static for all my static file, except maybe robots and favicon which cant be moved. As for StaticURLParser, using that as the first choice in the Cascade is wasteful cause it means pylons will do a file lookup for every request (bad performance) in addition to the fact that filenames may hijack pylons controller mapped routes (bad design calling for bugs). You can (and should) get rid of StaticURLParser and the Cascade if your web server is serving the static files (with a /static url prefix), or at least move StaticURLParser to the second choice in the Cascade when accessing the app directly from Paster http server (without a separate web server). My, he's opinionated. In a high-traffic situation you'd have Apache or your favorite webserver serve the static URLs before the application sees them, and then you can get rid of StaticURLParser and Cascade entirely. I'm not sure whether moving StaticURLParser after the Pylons application would be better or worse. My instinct is that it would be worse because a typical dynamic page has several static components. As for a filename hijacking a mapped route, I'm not sure what you mean. If you mean that with identical URLs, the static one is chosen, that's the programmer's problem; he should arrange the URLs so they don't overlap (and think about putting static files under a few well-known directories while he's at it). -- Mike Orr sluggos...@gmail.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Opinion sought on example.com/username
Hey thank for repeating what I said... when using a web server to serve the static files you should get rid of Cascade and staticURLParser. But the underlying question remains, how do you distinguish between static files and urls for which we defined dynamic controller actions ? One (bad) idea, is to first check if there is a static file matching the URL and serve it if it exists, otherwise try to find a dynamic controller action mapped to the URL. This behavior is the default for pylons and rails I believe. But like I said it has two main disadvantages : 1. You have to do a file lookup (e.g. system fstat() call) to determine if the static file exists before routing it to a controller. This is wasteful. 2. If a file exists with the same name as a URL defined in the route mapping for a dynamic controller action, then this file will be served instead of invoking the controller action. This can lead to bugs if you create a such a file by mistake. The above problems also happen in the case of using a web server that performs the static file existence check before proxying the request to pylons. Instead, it's MUCH better to separate the namespace by choosing different prefixes for static files and dynamic content. For example, all URLs for static files can start with /static, and/or all URLs for dynamic actions should start with /dynamic. There are TONS of fools on rails blogs/forums discussing what kind of apache directives to use to test for files existence to decide wether to serve the file or proxy the request etc. They don't understand that this whole problem could be solved with using URLs with different prefixes. Hope this clarifies my point On Dec 27, 4:59 pm, Mike Orr sluggos...@gmail.com wrote: On Sat, Dec 27, 2008 at 1:26 PM, Tycon adie...@gmail.com wrote: I use /static for all my static file, except maybe robots and favicon which cant be moved. As for StaticURLParser, using that as the first choice in the Cascade is wasteful cause it means pylons will do a file lookup for every request (bad performance) in addition to the fact that filenames may hijack pylons controller mapped routes (bad design calling for bugs). You can (and should) get rid of StaticURLParser and the Cascade if your web server is serving the static files (with a /static url prefix), or at least move StaticURLParser to the second choice in the Cascade when accessing the app directly from Paster http server (without a separate web server). My, he's opinionated. In a high-traffic situation you'd have Apache or your favorite webserver serve the static URLs before the application sees them, and then you can get rid of StaticURLParser and Cascade entirely. I'm not sure whether moving StaticURLParser after the Pylons application would be better or worse. My instinct is that it would be worse because a typical dynamic page has several static components. As for a filename hijacking a mapped route, I'm not sure what you mean. If you mean that with identical URLs, the static one is chosen, that's the programmer's problem; he should arrange the URLs so they don't overlap (and think about putting static files under a few well-known directories while he's at it). -- Mike Orr sluggos...@gmail.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Opinion sought on example.com/username
Previously ED209 wrote: I'm planning on moving my users' profile pages to: example.com/:username but there has been some discussion amongst fellow developers that this might cause problems. I would have this route and subsequent routes as the last ones defined in my array of routes defenitions so any static routes would be matched first. What if at some point in the future you need a new static route and a user already registered with that username? Wichert. -- Wichert Akkerman wich...@wiggy.netIt is simple to make things. http://www.wiggy.net/ It is hard to make things simple. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Opinion sought on example.com/username
On Sat, Dec 20, 2008 at 11:42 AM, Wichert Akkerman wich...@wiggy.net wrote: Previously ED209 wrote: I'm planning on moving my users' profile pages to: example.com/:username but there has been some discussion amongst fellow developers that this might cause problems. I would have this route and subsequent routes as the last ones defined in my array of routes defenitions so any static routes would be matched first. What if at some point in the future you need a new static route and a user already registered with that username? Well, that is where the Rails helpers' convention of /images, /stylesheets, and /javascripts makes some sense, because that way you only have to reserve a few prefixes. You could also reserve 'static' in case something else comes along that doesn't fit into these categories. -- Mike Orr sluggos...@gmail.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Opinion sought on example.com/username
Thanks for the replys. The only issues I can think of are: # Create a 404 type page for anyone going to a non-existing /:username # validate choice of /:username against routes # validation should also check an array of banned/legacy/reserved routes # if a user creates a :username which I later want as a static route - tough! I'll have to think of another name Apart from that I can't see any technical or performance issues? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Opinion sought on example.com/username
On Sat, Dec 20, 2008 at 1:57 PM, ED209 edleades...@gmail.com wrote: Thanks for the replys. The only issues I can think of are: # Create a 404 type page for anyone going to a non-existing /:username # validate choice of /:username against routes # validation should also check an array of banned/legacy/reserved routes # if a user creates a :username which I later want as a static route - tough! I'll have to think of another name Apart from that I can't see any technical or performance issues? No, it's just a regular routing variable. You may want to set a requirement to allow only word characters to prevent people from using offbeat symbols. -- Mike Orr sluggos...@gmail.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Opinion sought on example.com/username
You could go old-school: example.com/~username example.com/users/username isn't too bad, nor is Google's one- character approach (example.com/u/username). --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
