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.
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.
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/?
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.
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.
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/
> >
> > >
>
>
>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
