Hraban, On Sun, Oct 25, 2009 at 3:35 PM, Hraban Luyat <[email protected]> wrote: > > If possible, I would like to add two things to Adam's (excellent) > response. > > First: it is not web.py that is the odd one here, it is PHP. Many other > frameworks (Plone/Zope, Ruby on Rails, Django, ...) see the resource as > a resource, not as a file path (this is explicitly mentioned in the HTTP > specification, even). Adam is totally right about why this is > good/better, in my opinion.
Same response I gave above, PHP is not a framework, is a programming language. Python (if used without any framework), works just like PHP. > Second: there is a thing called mod_rewrite on most webservers that > allows you to play with the structure of your URLs even more. In fact, I > would argue that this lets people who do use PHP overcome exactly that > path-representation limitation, which is done extensively by large > projects like, say, MediaWiki (Wikipedia, etc). You can use mod_rewrite > to eliminate the /static/ from your URL structure. In some installations, mod_rewrite might not be available, and the PHP application I'm porting was installed simply by decompressing the PHP code inside the webroot, I don't want to add any extra requirements to the users just because I'm porting the code to python. > Now, one last thing that I would like to say myself: why do you not want > to use a webserver? I can strongly advice using something like LightTPD > or Apache, they are much more powerful than the built-in cherrypy > server. Unless you only need a small server for an unimportant project. > In which case: why bother about /static/? I want to be able to run the python code in web.py webserver, because I'm porting a hacking tool in order to integrate it with w3af [0]. The idea is that the users will be able to install the module I'm porting in a web server, and run it from there, or simply click on a button in my application and start the whole thing in their box. [0] http://w3af.sf.net/ > Putting it all together, let me show you what I usually do to overcome > the /static/ in the resource: I rewrite all URLs that end with a dot, > followed by three or four characters to prepend /static/. This means > that everything "with an extension" is considered a static file, the > rest is passed to web.py. You can do this with Squid, Lighttpd, Apache > (Apache allows more powerful rewrites, including rules like "first check > if the path exists as a file", but do not forget to jail that to the > /static/ dir to avoid leaks of server and template code), and even > web.py. > > Here is how you can do it in web.py: > > Create this rule: > > urls += (r'(.+\.\w{3,4})', 'static') > > And this handler class: > > class static: > def GET(self, name): > print >> sys.stderr, "Serving static resource", resource > raise web.tempredirect('/static/' + resource) > > This allows you to use resources without /static/ that will temporarily > be redirected to web.py friendly locations during debugging. Looks good, but I don't want to use mod_rewrite. I'm going to go for the "static_handler" I mentioned in my previous email. > To set this up for Lighttpd, you can check out this post: > <http://groups.google.com/group/webpy/msg/9bc7c54abb4875bc>. > > Good luck, and welcome to web.py, and also welcome away from PHP. Thanks for your answer! =) > Greetings, > > Hraban Luyat > > On Sun, Oct 25, 2009 at 00:08 -0400, Adam Atlas wrote: >> >> 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/ >> > >> > > >> >> >> > > > > -- Andrés Riancho Founder, Bonsai - Information Security http://www.bonsai-sec.com/ 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 -~----------~----~----~----~------~----~------~--~---
