On Wed, Jun 17, 2009 at 6:19 PM, donquixote<klabaut...@googlemail.com> wrote:
>
> On 17 Jun., 03:14, Graham Dumpleton <graham.dumple...@gmail.com>
> wrote:
>> On Jun 17, 10:04 am, donquixote <klabaut...@googlemail.com> wrote:
>>
>> > I would still be interested to read some arguments in favour of the
>> > trailing slash. From a user perspective, it seems that without is
>> > better.
>>
>> The big issue with trailing slash, is that you should use a trailing
>> slash on a URL which represents an internal node in the URL tree which
>> can have sub nodes and which is intended to represent some
>> conglomerated view or directory listing onto those sub nodes. One can
>> probably leave it off where URL represents a leaf node of the tree,
>> just not the internal nodes.
>
> I don't think this fits the mental models people usually have of
> websites. "This is a listing with child nodes" vs "This is a single
> node." And even then, a single node can have sub-pages - for instance,
> a page showing a user profile can have a subpage user/graham/blog.
>
> It's better to see it this way: Every page is an individual piece of
> content for itself, and still every page can have subpages.
>
> A directory, on the other hand, can have subpages, but is not that
> interesting for itself. Which we don't want to happen - we want all
> our pages to be interesting!
>

Think back to the days when all web pages were a collection of static
html files. Every directory within the server root had an index page
(usually index.html). That page could be found at any of the three
urls: `/path/to/dir`, `/path/to/dir/`, or `/path/to/dir/index.html`.
Obviously, not optimal. However, the recommendation was that the site
author always link to such pages consistently so that only one of
those urls would ever be used publicly. I think that's the "mental
model" Graham is talking about. As crazy as it sound, I recall seeing
someone who didn't like file extensions set up their site so that
every single page was an index page -- that is every single page was
in it's own directory, which may or may not have children. To easily
tell if a page had children or not, a slash was always used by the
author for pages that did and not for pages that did not.

Granted, the author and a few other dev types who he told about it are
probably the only people who ever noticed, but it made him feel
better. And that's really what this whole discussion is all about -
making the developer who chooses the url scheme feel good about it.
The fact is, whether the url I'm told over the phone should have a
slash at the end or not doesn't matter - it will lead me to the page I
want whether I type that ending slash or not (at least through a
redirect). Should Django support either choice by the site dev?
Perhaps. Does it really matter though? Not really. Which is probably
why the core devs have been completely silent on this issue.

If it hasn't happened already, file a bug as a "nice-to-have" feature
request, come up with the least invasive patch and wait for Django to
get out of feature freeze status (it is currently for the upcoming 1.1
release - bug fixes only right now) and bring it up during the next
proposal phase if it matters that much to you.

I don't mean to be dismissive of something some of you obvious care a
lot about, but this discussion has gone on endlessly and hasn't really
gone anywhere. And for the record, no, I'm not anyone important and
don't have any inside info on the core devs opinion, but I've seen
their silence before, and given Django current state (feature freeze),
well... there minds are focused elsewhere.

-- 
----
\X/ /-\ `/ |_ /-\ |\|
Waylan Limberg

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to