I totally understand why this is counterintuitive coming from PHP, as I wondered the exact same thing during my own "conversion" from PHP to Python/web.py. :)
Coming from PHP or any other CGI-like environment (i.e. an external server directly serves some files and executes some others), you'll need to shift your thinking a bit. You're not going to have URLs like "http://.../foo.py?something "; web.py (and most other Python web frameworks) don't impose that kind of automatic mapping between URLs and files -- and that's very much a feature. Unless you actually *are* just serving a tree of static files, that style results in a tradeoff between the potential for clean, expressive URLs and the ability to structure your code as you please. With web.py -- and most other Python web frameworks -- you don't have to compromise between the two. So you're not going to have URLs getting mapped directly to an "index.py" script and other .py files. Of course you can still call it index.py if you want, but that might reinforce that CGI/PHP mindset that doesn't apply here. Just try to forget about the idea of URLs referring to filesystem paths, *except* within the self-contained / static/ ghetto. Instead, design the "urls" list according to how you actually want your URLs to look, and understand that index.py (or whatever you rename it) represents your entire application, handling requests for *all* of your pages and dispatching them to library code accordingly -- not a file that is called externally to serve your site's index page living alongside co-equal .py files for other pages. The CGI/PHP style isn't necessarily bad, but that's not how web.py does it (and that's unlikely to change), and I think the web.py approach offers many significant advantages, once you get used to it. (For what it's worth, I've tried doing "line-to-line" ports from PHP to Python, and while the result might work, it might not be structured very well or take full advantage of Python's benefits. I usually find it's better to have a clear definition of the application's behavior and requirements, and to rebuild it from that, using pure Python idioms. I'm not saying you should throw away your existing code, but I'd use it more as a reference for building the new version, rather than doing a straight port.) - Adam On 24 Oct 2009, at 19:30, Andres Riancho wrote: > List, > > Hi, I'm new to webpy and also new to the list, so sorry if I'm > doing a stupid question ;) > > I'm porting a PHP application to Python using webpy. The PHP > application has a decent size, and my idea is to perform a "line to > line" port. One of the reasons I chose webpy was the ability to run > its own server, that would allow me to run this python application > without the need of Apache+mod_python. > > After porting the index, and trying it with "python index.py" , > I'm seeing that the HTML code that is generated (which is the same as > the PHP web application) is pointing to the correct locations for the > static files like ".js" and ".css", but the embedded webpy server > isn't serving those files. > > Quick google search, and I found that static files should all be > located in the "static" directory. My first thought was... these guys > have to be kidding, right? Is there a real reason for this? Why not > using the classic method of "running" the files with particular > extensions like ".py", and just reading the rest of the files? > > If I move all the static files, to the static directory, it would > only be needed for running in the embedded HTTP daemon, because Apache > wouldn't send the "run this" request to webpy for those files, right? > I think that the embedded HTTP daemon should mimic Apache as much as > possible. > > Am I the only one that finds this particularly annoying? > > I know that I could have just patched the "if" that matches the > static content, but that wouldn't have been useful for the > community ;) . If you guys tell me its ok, I could send you a patch > for webpy where all the "py" files are run, and the rest is treated as > static content. > > Cheers, > Andrés Riancho > http://w3af.sf.net/ > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "web.py" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/webpy?hl=en -~----------~----~----~----~------~----~------~--~---
