Eradicating "basepath"
Andrew McNabb
"basepath" nonsense. As much as I've hated it, I haven't been able to
get rid of it because the reverse url lookup wasn't working.
Fortunately, I have figured out a way to make this work--the 'urls'
branch has this working for some basic cases.
Unfortunately, getting rid of "basepath" will mean that everyone will
have to change their urls.conf and possibly their templates (anywhere
that "basepath" appears). While we're at it (and while our user base is
still relatively small), I think we should fix any other URL-related pet
peeves. Please let me know what has bothered you.
Here's a description of what I am currently planning to change. Let me
know what you like and dislike. A typical urls.py will look like this:
urlpatterns = patterns('',
(r'^andrew/linux/config/', include('smug.repo_urls'), {'repo': 'config'}),
(r'^andrew/smug/', include('smug.repo_urls'), {'repo': 'smug'}),
(r'^andrew/', include('smug.repo_urls'), {'repo': 'public_html'}),
(r'^andrew/', include('smug.urls')),
(r'^andrew/admin/doc/', include('django.contrib.admindocs.urls')),
(r'^andrew/admin/(.*)', admin.site.root),
)
This is much simpler than what we have right now because it removes the
basepath stuff. However, there a few other subtle differences. For
example, the smug urls module is split into two separate modules: one
for repo-specific urls and one for site-wide Smug urls. Things like
login and logout are part of the site-wide Smug urls. This gets rid of
the ":login" and ":logout" (the colons have been universally disliked),
but it avoids the problem of namespace collisions with your data. If
you have a directory in your repository called "login", then just change
the above pattern to something like:
(r'^andrew/smug-admin/', include('smug.urls')),
While we're at it, I would like to propose switching from putting a
":edit" at the end of each path name to something like "?edit". I think
that the CGI-query style would be more familiar looking, and it might
even make Smug a bit simpler internally. Having colons just hasn't
helped with any of the things that I was originally hoping that they
would help with.
Who likes the changes I've proposed, who dislikes them, and who's
indifferent? Are there any other URL-related things we should change
before it gets harder to do? (Smug 3k anyone? :)
--
Andrew McNabb
http://www.mcnabbs.org/andrew/
PGP Fingerprint: 8A17 B57C 6879 1863 DE55 8012 AB4D 6098 8826 6868
James Carroll
I will have to think about this... I do know that setting up the
basepaths right for multiple repos was a bit of a pain, but I am not
sure that I like this better yet, perhaps we should talk in person on
Friday.
I didn't dislike the : thing, I thought it was fine, but I am not
picky about stuff like this, so if it was bothering others, why not go
ahead and fix it?
James
"And very early in the morning
the first day of the week,
they came unto the sepulchre
at the rising of the sun..." (Mark 16:2)
Web: http://james.jlcarroll.net
Andrew McNabb
>
> Anyone who's done anything serious with Smug has come to hate the
> "basepath" nonsense. As much as I've hated it, I haven't been able to
> get rid of it because the reverse url lookup wasn't working.
> Fortunately, I have figured out a way to make this work--the 'urls'
> branch has this working for some basic cases.
I rewrote the request dispatching stuff in the urls branch. Now the
urls.py and views/__init__.py are much more simple. I think that it's
easier to follow where things are going now.
I forgot to describe how templates have changed in this branch. Since
we're using reverse urls correctly now, we don't have to pass basepath
around anymore. Where an href might have earlier been set to "{{
basepath }}/style.css", we now specify: "{% url smug-page "style.css"
%}". The word "smug-page" is what I used to name the Django url entry.
I'm not sure that I really like "smug-page", so let me know if you have
something better (anything works, as long as it's not likely to conflict
with other Django apps).
I'm really curious for feedback on this stuff. Don't feel like you have
to look at the code--high-level thoughts are great.
Thanks.
James Carroll
in the template with another. How is this better? More importantly, I
used to set up different basepaths for each repo... but now, I am
unsure how to do the equivalent if I have a multiple repo system? How
does using reverse urls correctly solve this problem? Perhaps I am
just exposing my ignorance about all things http. I think I just need
more information about reverse url's. I did some quick googling and
didn't find much that helped me understand how this would work.
More info please.
James
Andrew McNabb
>
> I guess I need more information, you just replaced one magic thingey
> in the template with another. How is this better? More importantly, I
> used to set up different basepaths for each repo... but now, I am
> unsure how to do the equivalent if I have a multiple repo system? How
> does using reverse urls correctly solve this problem? Perhaps I am
> just exposing my ignorance about all things http. I think I just need
> more information about reverse url's. I did some quick googling and
> didn't find much that helped me understand how this would work.
>
> More info please.
Hmm. You raise some good questions.
In the simple case, removing basepath does two great things. First, it
makes it much easier for users to set up Smug without making mistakes.
Earlier users had to add a basepath term to the regular expression,
which was unintuitive and brittle (pretty much everyone struggled
setting this up). Second, removing basepath simplified the code a lot
by having one less big thing to send to every single function.
Basepath-related stuff was a source of a large number of bugs.
So, in the simple case with a unified site, this is a big improvement.
Not surprisingly, my site falls under this category. My "smug" section
is pulled from the smug repository, but from the outside, it looks like
it's part of the same site.
In your case, with multiple distinct subsections, this probably doesn't
help so much. My first reaction is that it might make sense to have a
separate Django project for subsection. I'll keep on thinking about
this because I'm sure that there's some way to make things work for both
types of sites.
Andrew McNabb
>
> In your case, with multiple distinct subsections, this probably doesn't
> help so much. My first reaction is that it might make sense to have a
> separate Django project for subsection. I'll keep on thinking about
> this because I'm sure that there's some way to make things work for both
> types of sites.
James, I realized that there's a really easy way to do this. I only had
to add a few lines to compute the "baseurl" (url of the base of the
repository). Fortunately, this can happen in the filter code, so it
doesn't add extra stuff to pass around. Anyway, this is now in the
"urls" branch.
I'm not really fond of the name "baseurl", since this originally meant
"the url to the base of the Smug site" whereas it turned out to mean
"the url to the base of the current repository". I'm not sure it's
worth changing the name because it would break backwards compatibility.
What do you think?
James Carroll
without giving it too much thought, I don't think that the name
matters that much.
But it is cool that you found a way to make multiple repos easier to
deal with, when I get home I will have to try out the new branch and
see how it works.
J
Jonathan Wilson
>
> makes it much easier for users to set up Smug without making mistakes.
> Earlier users had to add a basepath term to the regular expression,
> which was unintuitive and brittle (pretty much everyone struggled
> setting this up). Second, removing basepath simplified the code a lot
> by having one less big thing to send to every single function.
> Basepath-related stuff was a source of a large number of bugs.
I like this getting rid of basepath - not only does it hamper the DRY
principle, even with how it is now being so much better than how it was
when smug first came out. Also, having reverse urls working would be
awesome, and make quite a few things better - especially for the more
statically oriented pages (does {% url %} work with rst in anyway?)?
--
Jonathan Wilson
Andrew McNabb
>
> I like this getting rid of basepath - not only does it hamper the DRY
> principle, even with how it is now being so much better than how it was
> when smug first came out. Also, having reverse urls working would be
> awesome, and make quite a few things better - especially for the more
> statically oriented pages (does {% url %} work with rst in anyway?)?
That's a really good question. Jeff is our resident RestructuredText
expert. Hopefully he can chime in on this—I'm really not sure what
would be the best way to do these links in rst.
Jeff Anderson
I'm very much in favor of dropping the :login and :logout "actions" that
can be tacked on to the end of any url. Moving them to their own
dedicated location will be very nice, and will remove the "what the
heck?" thoughts that may go through and end user's head. Even though I
am in favor of this change, I would also like to say that we should
probably drop the login/logout functionality from smug altogether. This
is in the spirit of keeping Django apps as pluggable as possible.
As for dropping :edit in favor of using a GET parameter, I'm a huge +1
on that.
Andrew McNabb
>
> I'm very much in favor of dropping the :login and :logout "actions" that
> can be tacked on to the end of any url. Moving them to their own
> dedicated location will be very nice, and will remove the "what the
> heck?" thoughts that may go through and end user's head. Even though I
> am in favor of this change, I would also like to say that we should
> probably drop the login/logout functionality from smug altogether. This
> is in the spirit of keeping Django apps as pluggable as possible.
I originally tried to use the login and logout from admin.
Unfortunately, there was something they did that was very wrong. I
can't remember exactly what it was, but you could go and compare the two
implementations. In any case, Smug's login and logout pages use normal
Django sessions, so there shouldn't be any ill effect on pluggability.
> As for dropping :edit in favor of using a GET parameter, I'm a huge +1
> on that.
Cool. I have this working in the urls branch--feel free to try it out.
I'll merge it into master sometime today or tomorrow if no one has any
complaints.
James Carroll
without basepath?
James
Andrew McNabb
I still have to update the documentation, and there could be some more
tweaking needed.