Case-insensitive URLS (was: usability issues)
Jacob Kaplan-Moss
> ** I've posted corresponding ticket.
> http://code.djangoproject.com/ticket/5090
> Now it is closed as "won't fix". At least the resolution should be
> changed to "By Design" if you guys don't like sites built on django
> being convenient.
OK, so before I address your question I need to deal with some
administrivia first:
(A) Being a dick will get you exactly nowhere. I'm going to assume
that you didn't mean to troll here and actually answer your question.
Uou should know that when you use this tone, you're likely just to
piss people off, and that's exactly the wrong way to make an argument.
(B) Reopening tickets because you disagree with the resolution is also
quite impolite. Bringing the issue here is the right way to go, but
leave the ticket closed unless you can convince us to rep-open it.
Right, so moving on to your real question:
> Here is an example of case-insensitive urls. They rock:
> http://www.askeri.ru/PUBLISH/
> http://www.askeri.ru/publish/
They do indeed rock. Luckily, supporting them is super-easy::
(r'(?P<slug>[\w]+)/$', my_view)
...
def my_view(request, slug):
o = MyObject.objects.get(slug__iexact=slug)
Bingo; case-insensitive URLs! Rock on.
The point is this: if we hard-code case-insensitivity into Django,
then developers won't be able to produce case-sensitive URLs if they
need to. If, however, we don't hardcode anything, developers can do
whatever they want.
If we introduce this very small convenience, we'll be taking power
away from developers. That goes directly against Django's
> * What do you think about including Web Typography support as a
> built-in django feature?
I think it's a great idea. We currently don't have a process by which
apps are added to contrib, and that's the only thing holding us back.
I'm working on proposing such a process, and once the development
community has had a chance to tell me where I got it wrong, typography
is one of the first things I'd like to propose for addition to
contrib.
Jacob
Alex Nikolaenkov
below. Thank you for your responses.
> On 8/5/07, Alex Nikolaenkov <nikol...@actimind.com> wrote:
>> ** I've posted corresponding ticket.
>> http://code.djangoproject.com/ticket/5090
>> Now it is closed as "won't fix". At least the resolution should be
>> changed to "By Design" if you guys don't like sites built on django
>> being convenient.
> OK, so before I address your question I need to deal with some
> administrivia first:
> (A) Being a dick will get you exactly nowhere. I'm going to assume
> that you didn't mean to troll here and actually answer your question.
> Uou should know that when you use this tone, you're likely just to
> piss people off, and that's exactly the wrong way to make an
> argument.
Agreed. I admire your wisdom.
> (B) Reopening tickets because you disagree with the resolution is also
> quite impolite. Bringing the issue here is the right way to go, but
> leave the ticket closed unless you can convince us to rep-open it.
I never heard that tickets should not be reopened if you disagree. If
the bug is still reproducible it should be reopened. If its
resolution is changed to "won't fix", one should point why. And
not just - "Oh, it is good enough now". The only one who CLOSES the
ticket is the opener. So it's also very impolite to CLOSE TICKETS FOR
SOMEONE. Correct me if I'm wrong.
> Right, so moving on to your real question:
>> Here is an example of case-insensitive urls. They rock:
>> http://www.askeri.ru/PUBLISH/
>> http://www.askeri.ru/publish/
> They do indeed rock. Luckily, supporting them is super-easy::
> (r'(?P<slug>[\w]+)/$', my_view)
> def my_view(request, slug):
> o = MyObject.objects.get(slug__iexact=slug)
> Bingo; case-insensitive URLs! Rock on.
That's understood. But this code smells bad. Dont you think so?
F.e. most even do not know what '(?: )' means. Furthermore view is not
the right place to parse urls. View is a formatting object in my
viewpoint. Just like the XSLT template. When I was writing this
post I've suddenly realized that case insensitive urls can be easily
made in production with mod_rewrite. Me bad.
BTW, Can we attach configurable plug-ins to the built-in webserver?
(* I'm interested in possibility. Can code "case insensitive urls
plug-in" by myself. *)
> The point is this: if we hard-code case-insensitivity into Django,
> then developers won't be able to produce case-sensitive URLs if they
> need to. If, however, we don't hardcode anything, developers can do
> whatever they want.
HARD-CODING IS EVIL. PAUSE. I've proposed the SIMPLIEST and the UGLIEST
solution. I learn django for 2 days as well as python. So I can
easily have incorrect understanding of the big picture. BTW I was
really surprised when found out that django uses TDD. It's cool. Just
like case-insensitive urls. ;) Feel free to tell that I'm wrong. I'll
think about it once more. First impressions - great language, great
framework. Thank you all for it.
> If we introduce this very small convenience, we'll be taking power
> away from developers. That goes directly against Django's
+1. When I saw hardcoded flag values I thought just like this.
--
Best regards,
Alex mailto:nikol...@actimind.com
Mikhail Gusarov
Twas brillig at 09:49:49 06.08.2007 UTC+04 when Alex Nikolaenkov did gyre and gimble:
AN> BTW, Can we attach configurable plug-ins to the built-in webserver? (* I'm
AN> interested in possibility. Can code "case insensitive urls plug-in" by
AN> myself. *)
I already pointed out that Django middleware is the proper place for such
things. Please read the documentation about middleware, and you'll see how easy
it is to add such functionality as case-insensitive URLs (keeping in mind that
case-insensitive URLs should not affect business logic - imagine you have API
for application: it would be very disturbing to have case-insensitvie API).
--
JID: dott...@jabber.dottedmag.net
Jacob Kaplan-Moss
> BTW, Can we attach configurable plug-ins to the built-in webserver?
> (* I'm interested in possibility. Can code "case insensitive urls
> plug-in" by myself. *)
You're looking for "middleware":
http://www.djangoproject.com/documentation/middleware/ or
http://www.djangobook.com/en/beta/chapter16/.
Jacob
Kai Kuehne
On 8/6/07, Alex Nikolaenkov <nikol...@actimind.com> wrote:
> > Right, so moving on to your real question:
> >> Here is an example of case-insensitive urls. They rock:
> >> http://www.askeri.ru/PUBLISH/
> >> http://www.askeri.ru/publish/
>
> > They do indeed rock. Luckily, supporting them is super-easy::
> > (r'(?P<slug>[\w]+)/$', my_view)
> > def my_view(request, slug):
> > o = MyObject.objects.get(slug__iexact=slug)
> > Bingo; case-insensitive URLs! Rock on.
> That's understood. But this code smells bad. Dont you think so?
> F.e. most even do not know what '(?: )' means. Furthermore view is not
> the right place to parse urls. View is a formatting object in my
> viewpoint. Just like the XSLT template.
Please just learn django. Thank you.
Jacob Kaplan-Moss
> Please just learn django. Thank you.
Hey, that's out of line. Around here we treat everyone with respect;
Alex deserves better. Next time you feel the urge to post something of
this nature, take it to Digg.
Only *you* can prevent flamewars!
Jacob
Tom Tobin
> the bug is still reproducible it should be reopened. If its
> resolution is changed to "won't fix", one should point why. And
> not just - "Oh, it is good enough now". The only one who CLOSES the
> ticket is the opener. So it's also very impolite to CLOSE TICKETS FOR
> SOMEONE. Correct me if I'm wrong.
You're (partially) wrong. ^_^
If a core dev closes a ticket with a "wontfix", you shouldn't re-open
the ticket unless you've made a compelling case on django-dev and
gotten the core devs to change their minds. "Wontfix" essentially
means that a design decision has been made against the proposal, and
re-opening the ticket isn't going to change that.
If you can still reproduce a bug after it has been closed as "fixed",
yes, you should re-open the relevant ticket while stating as much.
If a ticket has been closed as "invalid", you should only re-open it
if you're certain the issue really is with Django rather than
something else. If in doubt, ask django-users for help regarding such
an issue.
Yes, whenever a ticket is closed, it should have a reason attached; if
one is missing, feel free to comment on the ticket asking for a reason
— but *without* re-opening the ticket.
Alex Nikolaenkov
> Jacob
Thank you very much. I haven't read the whole djangobook yet.
I've got: here is not the right place to ask such questions.
But they do arise in my head while typing. Just skip if they bother.
I WILL answer them by myself. Still very green in python, but will
learn rapidly. You'll see.
I promise: no questions till I read the whole djangobook. I'll
write'em down and try to answer by myself & google after reading. If
no answer is found, I'll post them here.
~ Alex mailto:nikol...@actimind.com
Alex Nikolaenkov
>>
>> I never heard that tickets should not be reopened if you disagree. If
>> the bug is still reproducible it should be reopened. If its
>> resolution is changed to "won't fix", one should point why. And
>> not just - "Oh, it is good enough now". The only one who CLOSES the
>> ticket is the opener. So it's also very impolite to CLOSE TICKETS FOR
>> SOMEONE. Correct me if I'm wrong.
> You're (partially) wrong. ^_^
> If a core dev closes a ticket with a "wontfix", you shouldn't re-open
> the ticket unless you've made a compelling case on django-dev and
> gotten the core devs to change their minds. "Wontfix" essentially
> means that a design decision has been made against the proposal, and
> re-opening the ticket isn't going to change that.
How can I find out that the one closed is the core dev? ^_^ I thought that
ticket was closed by a few volunteers reviewing them first (volunteers
are mentioned near the bug-reviewing-process-scheme).
Here is much of django process issues. Thanks for clarification. BTW
where can I find list of core developers?
> Yes, whenever a ticket is closed, it should have a reason attached; if
> one is missing, feel free to comment on the ticket asking for a reason
> -- but *without* re-opening the ticket.
BTW I can't get why reopening tickets is treated as the major issue.
Just one more ticket. Just a message. Just a discussion. And so on. If
I request for comments without re-opening, time consumption is much the
same. So what's the difference?
Tom Tobin
> > If a core dev closes a ticket with a "wontfix", you shouldn't re-open
> > the ticket unless you've made a compelling case on django-dev and
> > gotten the core devs to change their minds. "Wontfix" essentially
> > means that a design decision has been made against the proposal, and
> > re-opening the ticket isn't going to change that.
>
> How can I find out that the one closed is the core dev? ^_^ I thought that
> ticket was closed by a few volunteers reviewing them first (volunteers
> are mentioned near the bug-reviewing-process-scheme).
> Here is much of django process issues. Thanks for clarification. BTW
> where can I find list of core developers?
Well, a volunteer / triager might also close it as "wontfix" if it's
been made clear in the past by a core dev that such a decision has
been made, and in these cases the same thing applies. (They should
hopefully point this out in the close comment.) The core devs are the
people listed as "primary authors" here:
http://code.djangoproject.com/browser/django/trunk/AUTHORS
> > Yes, whenever a ticket is closed, it should have a reason attached; if
> > one is missing, feel free to comment on the ticket asking for a reason
> > -- but *without* re-opening the ticket.
>
> BTW I can't get why reopening tickets is treated as the major issue.
> Just one more ticket. Just a message. Just a discussion. And so on. If
> I request for comments without re-opening, time consumption is much the
> same. So what's the difference?
Developers use the "open" status of a ticket to track if it needs to
be addressed; that's why the "open" status of a ticket matters. If
something has been closed for a valid reason, there needs to be a
*good* reason to re-open it; developer time is scarce and tickets are
plenty. It has nothing to do with stifling discussion, and everything
to do with making efficient use of limited time. You're more than
welcome to raise a discussion here regarding the closing of a ticket
when you disagree with the reasoning; you're also welcome to post a
comment on the ticket while leaving it closed. If you change minds
regarding the issue, the ticket will get re-opened.
Alex Nikolaenkov
Thank you for clarification. Now that makes a lot of sense for me.
~ Alex
> http://code.djangoproject.com/browser/django/trunk/AUTHORS
Malcolm Tredinnick
[...]
> > (B) Reopening tickets because you disagree with the resolution is also
> > quite impolite. Bringing the issue here is the right way to go, but
> > leave the ticket closed unless you can convince us to rep-open it.
> I never heard that tickets should not be reopened if you disagree.
I realise that you are just getting used to the way we (and other
projects, no doubt) work, so don't take this too personally. However,
there are some common misunderstandings here, so a quick post for the
archives might be useful for the future...
A fairly standard practice is to read a project's contributing
documentation if you are unsure. In this case, contributing.txt -- also
online at http://www.djangoproject.com/documentation/contributing/ --
says, in the section about reporting bugs:
Don't reopen issues that have been marked "wontfix". This mark
means that the decision has been made that we can't or won't fix
this particular issue. If you're not sure why, please ask on
`django-developers`_.
That's fairly normal Open Source project practice, too. At some point,
somebody has to get final say as to when the open/close/reopen/reclose
cycle ends and we try to head that off early. Tickets don't get
"wontfixed" for trivial reasons, so we ask that people respect that.
> If
> the bug is still reproducible it should be reopened.
There is frequently debate about what is a "bug", though.
"Wontfix" (along with "invalid") is the maintainers' way of saying "this
isn't a bug". Very rarely it's "this is a bug, but we aren't going to
fix it for this reason" (usually because the code in question is
deprecated and only exists for backwards compatible use and the bug is
very minor).
> If its
> resolution is changed to "won't fix", one should point why. And
> not just - "Oh, it is good enough now". The only one who CLOSES the
> ticket is the opener. So it's also very impolite to CLOSE TICKETS FOR
> SOMEONE. Correct me if I'm wrong.
Bug tickets in Open Source projects are almost never closed by the
person who opened them. They are closed by the person who fixes them or
determines they are not a bug or whatever. Those people are invariably
people qualified to make such decisions, so it's not like random people
are going to be closing tickets (we keep a close eye on that and reopen
tickets that are closed without reason or by anonymous people).
Regards,
Malcolm
--
Remember that you are unique. Just like everyone else.
http://www.pointy-stick.com/blog/
Alex Nikolaenkov
Thank you for clarification. Just getting used to the open-source
project. BTW feeling myself very strange, because experience only in
commercial software is available :-)
~Alex
> Regards,
> Malcolm
--
Mike H
> Don't reopen issues that have been marked "wontfix". This mark
> means that the decision has been made that we can't or won't fix
> this particular issue. If you're not sure why, please ask on
> `django-developers`_.
>
> That's fairly normal Open Source project practice, too. At some point,
> somebody has to get final say as to when the open/close/reopen/reclose
> cycle ends and we try to head that off early. Tickets don't get
> "wontfixed" for trivial reasons, so we ask that people respect that.
>
>
On a half-related note, I notice that a particular behaviour that I keep
django patched to avoid (case sensitive usernames in contrib.auth) has
been marked as "wontfix" with the reason " We just don't have time." (
http://code.djangoproject.com/ticket/2273 )
If I do the work to change the behavior (ideally, having it configurable
which behavior to use) and reopen that ticket with an acceptable patch,
is there a chance it might be accepted?
Cheers,
Mike