On Thu, 2009-03-05 at 13:35 +0100, Dries Desmet wrote:
> Hi all,
>
> I want to start a very simple tree-structure cms django app. Reading
> about django all day yesterday, my plan is to have the urlconf capture
> every and all urls by:
> (r'', 'pages.views.index')
>
> and use the request.url object to differentiate between the pages by
> checking them against a .url attribute of the pages model.
> If request.url="/" I have to be at the index page, right?
No. There could be a "script name" on the front of that. So if the
webserver is configured to only pass everything under, say, "/foo/bar/"
to Django, then a request for "/foo/bar/" will show appear to Django as
being a request for "/".
> So it 'll be something like
> try:
> pages.object.get(url=request.url)
>
> except:
> return a 404
Based on the complete lack of code you've provide about what pages exist
and what the page model is, it's difficult to tell what's going on
there, so I'll skip this.
>
>
> 1) Is it good practice to have a urlconf capture everything
Only if you want to capture everything. That's pretty rare. Most
projects have multiple URL patterns to match different things and send
them to different views.
> and is my regex of empty string waterproof?
Your URLConf pattern will match *everything*, but capture nothing. Not
just every request for '/'. If you want to match just '/', then do just
that, with a pattern like:
'/$'
> 2) Is r'^.*$' any better?
That will also match everything, except that it will consume it (and not
capture anything, since you don't have any grouping parentheses), rather
than simply matching the "nothing" at the start of the string.
> 3) Why do most examples use (?P<url>) to capture the url instead of
> request.url that gets passed to the view anyway already?
Because most patterns aren't trying to capture everything. That avoids
the whole benefit of the URL Conf, section and simply passes exactly the
same amount of work into the view. The URL Conf pattern is used to split
things up into components so that view functions look like standard
Python functions with a bunch of readable arguments passed in.
Oh, and by the way, request.url doesn't seem to exist, either, so I'm
not sure what you're doing there. Certainly nothing in
django/core/handlers/* assigns to that attribute and the string
"request.url" doesn't appear anywhere in the source tree.
Regards,
Malcolm
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django users" 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/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
