Re: append_slash alternative: remove_slash

[M. N. Islam Shihan]

Thanks for pointing me to the bikeshed. It is an excellent topic that  
I wasn't aware of.

Anyway, I'm still not understanding how this topic relates to my reply.

On Jun 17, 2009, at 6:25 AM, Russell Keith-Magee  
 wrote:

>
> On Wed, Jun 17, 2009 at 5:02 AM, M. N. Islam  
> Shihan wrote:
>>
>> On Jun 17, 2009, at 2:27 AM, Hanne Moa  wrote:
>>>
>>> And I want the bikeshed to be painted blue with yellow stars on.
>>
>> ???
>
> For an explanation, see http://www.bikeshed.com/
>
> For extra amusement, reload the page a few times :-)
>
> Yours,
> Russ Magee %-)
>
> >

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: append_slash alternative: remove_slash

[donquixote]

You are right!
I always had assumed the browser would understand these relative urls
no matter if slash or not. I made a test, and it turns out I was
wrong.

A lot of websites out there either don't use relative urls, or they
use a  tag etc.
Others (such as wikipedia) make their URLs relative to web root, with
a preceding slash.

For a user I would say it looks nicer without the slash, but it's only
a subtle difference. So.. I can see how someone would prefer urls with
slash, or even a mixed system where only "leave" nodes have no slash.
I am curious how many developers actually use relative urls without a
base tag, where they can take advantage of the slash.

On Jun 17, 3:14 am, Graham Dumpleton 
wrote:
> On Jun 17, 10:04 am, donquixote  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.
>
> The reason for this is that by not having a trailing slash on URLs for
> internal nodes, then if the response uses relative URLs to refer to
> sub nodes, it will tend to break where trailing slash wasn't used.
> This is because for trailing slash, you only need to have the sub node
> name in relative URL because the browser will correctly then join them
> together no problems. If the trailing slash is not present, then
> relative URLs referring to sub nodes, would also need to include the
> name of the directory node as the browser would otherwise drop the
> internal node name of URL without the trailing slash before joining
> them together.
>
> So, although leaving off trailing slashes may make it look nicer, you
> potentially break things because of how browsers work, or at least
> make generation of relative URLs in responses a PITA.
>
> > But of course, I don't want to take away anyone's APPEND_SLASH
> > setting. For an existing system, I think it's the best to keep the
> > slashes.
>
> > 
>
> > Please also note how the original proposal is made up of two ideas:
> > 1. clean up the url typed by the user (by whatever standards you
> > want), and redirect to the cleaned-up version. This will make the
> > system tolerant to user input, but prevents undesired alias names from
> > going into bookmarks or search engines.
>
> Which for repeating slashes cannot be done if hosting through Apache
> as the repeating slashes are collapsed and not present in SCRIPT_NAME
> or PATH_INFO. You therefore don't really know that repeating slashes
> existed in order to trigger a redirect.
>
> That there were repeating slashes is still recorded in REQUEST_URI,
> but you shouldn't use that directly as there isn't necessarily a
> direct relationship between that and SCRIPT_NAME and PATH_INFO because
> of rewriting that may occur in Apache.
>
> The only sort of redirect that generally would be done, is to force a
> URL without a trailing slash and which refers to an internal node in
> URL tree, to have a trailing slash appended so that those relative
> URLs work. Doing this means that user can use URL without trailing
> slash if they want, but application will ensure that browser adds one
> such that things work properly.
>
> So, what is the real issue here? That you don't like that the browser
> shows a trailing slash when on a URL representing an internal node, or
> that the user has to have the trailing slash when they enter the URL
> because the application isn't properly redirecting the browser to use
> a trailing slash when it should be.
>
> Graham
>
>
>
> > 2. The dispatcher tries the regex route definitions with two different
> > versions of the request url (with priority rules of your choice). This
> > allows the programmer to write sloppy regex, which can make the job a
> > lot easier. It also allows to include url definitions from packages
> > which assume a different slash policy.
>
> > As has been pointed out by others in this thread, the policy of slash
> > or not slash should be consistent within one project, so most projects
> > will not need to make this decision again for every single route
> > definition.
>
> > On Jun 17, 1:07 am, Graham Dumpleton 
> > wrote:
>
> > > On Jun 16, 10:55 pm, Justin Myers  wrote:
>
> > > > On Jun 16, 3:49 am, Ivan Sagalaev  wrote:
>
> > > > > Indeed I don't really want to discuss the proposal itself (I don't
> > > > > really care of the outcome since you don't propose to remove
> > > > > APPEND_SLASH altogether). I was just trying to show that bashing some
> > > > > 

Re: append_slash alternative: remove_slash

[Graham Dumpleton]

On Jun 17, 10:04 am, donquixote  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.

The reason for this is that by not having a trailing slash on URLs for
internal nodes, then if the response uses relative URLs to refer to
sub nodes, it will tend to break where trailing slash wasn't used.
This is because for trailing slash, you only need to have the sub node
name in relative URL because the browser will correctly then join them
together no problems. If the trailing slash is not present, then
relative URLs referring to sub nodes, would also need to include the
name of the directory node as the browser would otherwise drop the
internal node name of URL without the trailing slash before joining
them together.

So, although leaving off trailing slashes may make it look nicer, you
potentially break things because of how browsers work, or at least
make generation of relative URLs in responses a PITA.

> But of course, I don't want to take away anyone's APPEND_SLASH
> setting. For an existing system, I think it's the best to keep the
> slashes.
>
> 
>
> Please also note how the original proposal is made up of two ideas:
> 1. clean up the url typed by the user (by whatever standards you
> want), and redirect to the cleaned-up version. This will make the
> system tolerant to user input, but prevents undesired alias names from
> going into bookmarks or search engines.

Which for repeating slashes cannot be done if hosting through Apache
as the repeating slashes are collapsed and not present in SCRIPT_NAME
or PATH_INFO. You therefore don't really know that repeating slashes
existed in order to trigger a redirect.

That there were repeating slashes is still recorded in REQUEST_URI,
but you shouldn't use that directly as there isn't necessarily a
direct relationship between that and SCRIPT_NAME and PATH_INFO because
of rewriting that may occur in Apache.

The only sort of redirect that generally would be done, is to force a
URL without a trailing slash and which refers to an internal node in
URL tree, to have a trailing slash appended so that those relative
URLs work. Doing this means that user can use URL without trailing
slash if they want, but application will ensure that browser adds one
such that things work properly.

So, what is the real issue here? That you don't like that the browser
shows a trailing slash when on a URL representing an internal node, or
that the user has to have the trailing slash when they enter the URL
because the application isn't properly redirecting the browser to use
a trailing slash when it should be.

Graham

> 2. The dispatcher tries the regex route definitions with two different
> versions of the request url (with priority rules of your choice). This
> allows the programmer to write sloppy regex, which can make the job a
> lot easier. It also allows to include url definitions from packages
> which assume a different slash policy.
>
> As has been pointed out by others in this thread, the policy of slash
> or not slash should be consistent within one project, so most projects
> will not need to make this decision again for every single route
> definition.
>
> On Jun 17, 1:07 am, Graham Dumpleton 
> wrote:
>
>
>
> > On Jun 16, 10:55 pm, Justin Myers  wrote:
>
> > > On Jun 16, 3:49 am, Ivan Sagalaev  wrote:
>
> > > > Indeed I don't really want to discuss the proposal itself (I don't
> > > > really care of the outcome since you don't propose to remove
> > > > APPEND_SLASH altogether). I was just trying to show that bashing some
> > > > people's preference doesn't help in making a point. Feel free to ignore
> > > > the advice.
>
> > > Which hopefully will bring us back on topic: Regardless of our
> > > individual feelings on the trailing-slash holy war here, Patrick said
> > > it best--let's have a way to get rid of the URLs we agree are bad
> > > (multiple consecutive slashes)
>
> > What hosting mechanism are you using? From memory Apache with
> > mod_python, mod_wsgi and possibly even mod_fastcgi or mod_fcgid should
> > see the repeating slashes be collapsed by Apache. I can't check this
> > at the moment, otherwise I would. :-)
>
> > Graham
>
> > > and a way to choose whether we want to
> > > append or remove the trailing slash.
>
> > > The whole point is consistency in order to help keep our search
> > > results and rankings in line--which I think we can all agree is a Good
> > > Thing. Anyone interested in 

Re: append_slash alternative: remove_slash

[donquixote]

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.

But of course, I don't want to take away anyone's APPEND_SLASH
setting. For an existing system, I think it's the best to keep the
slashes.



Please also note how the original proposal is made up of two ideas:
1. clean up the url typed by the user (by whatever standards you
want), and redirect to the cleaned-up version. This will make the
system tolerant to user input, but prevents undesired alias names from
going into bookmarks or search engines.
2. The dispatcher tries the regex route definitions with two different
versions of the request url (with priority rules of your choice). This
allows the programmer to write sloppy regex, which can make the job a
lot easier. It also allows to include url definitions from packages
which assume a different slash policy.

As has been pointed out by others in this thread, the policy of slash
or not slash should be consistent within one project, so most projects
will not need to make this decision again for every single route
definition.



On Jun 17, 1:07 am, Graham Dumpleton 
wrote:
> On Jun 16, 10:55 pm, Justin Myers  wrote:
>
> > On Jun 16, 3:49 am, Ivan Sagalaev  wrote:
>
> > > Indeed I don't really want to discuss the proposal itself (I don't
> > > really care of the outcome since you don't propose to remove
> > > APPEND_SLASH altogether). I was just trying to show that bashing some
> > > people's preference doesn't help in making a point. Feel free to ignore
> > > the advice.
>
> > Which hopefully will bring us back on topic: Regardless of our
> > individual feelings on the trailing-slash holy war here, Patrick said
> > it best--let's have a way to get rid of the URLs we agree are bad
> > (multiple consecutive slashes)
>
> What hosting mechanism are you using? From memory Apache with
> mod_python, mod_wsgi and possibly even mod_fastcgi or mod_fcgid should
> see the repeating slashes be collapsed by Apache. I can't check this
> at the moment, otherwise I would. :-)
>
> Graham
>
>
>
> > and a way to choose whether we want to
> > append or remove the trailing slash.
>
> > The whole point is consistency in order to help keep our search
> > results and rankings in line--which I think we can all agree is a Good
> > Thing. Anyone interested in working on it?
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: append_slash alternative: remove_slash

[Graham Dumpleton]

On Jun 16, 10:55 pm, Justin Myers  wrote:
> On Jun 16, 3:49 am, Ivan Sagalaev  wrote:
>
> > Indeed I don't really want to discuss the proposal itself (I don't
> > really care of the outcome since you don't propose to remove
> > APPEND_SLASH altogether). I was just trying to show that bashing some
> > people's preference doesn't help in making a point. Feel free to ignore
> > the advice.
>
> Which hopefully will bring us back on topic: Regardless of our
> individual feelings on the trailing-slash holy war here, Patrick said
> it best--let's have a way to get rid of the URLs we agree are bad
> (multiple consecutive slashes)

What hosting mechanism are you using? From memory Apache with
mod_python, mod_wsgi and possibly even mod_fastcgi or mod_fcgid should
see the repeating slashes be collapsed by Apache. I can't check this
at the moment, otherwise I would. :-)

Graham

> and a way to choose whether we want to
> append or remove the trailing slash.
>
> The whole point is consistency in order to help keep our search
> results and rankings in line--which I think we can all agree is a Good
> Thing. Anyone interested in working on it?
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Focusing on inlines this week

[Margie]

I really like this, Zain.  And the "add another" will be a great
addition as well.

Also (getting back to your autocomplete stuff) the more I have thought
about the autocomplete widget, the more I like it. I have experimented
quite a bit with other alternatives over the past few weeks, and
having done that, I have come around in my thinking.  I actually think
that autocomplete is probably the most general solution and a very
good addition.  Sorry if my comments caused you to divert from this in
any way!


Margie



On Jun 8, 11:35 pm, Zain Memon  wrote:
> This week, I checked in support for selector inlines, and I've made progress
> on implementing a link to add and remove extra inlines dynamically.
>
> Selector inlines are the implementation of a mockup[1] Wilson Miner created
> with the intention of replacing stacked inlines. The basic idea is that
> clicking on a row selects it, and the fields on the right are populated with
> the information for the currently selected inline object. I decided to make
> selector inlines a separate option instead of replacing stacked inlines.
>
> I'm also working on dynamically adding and removing extra inline objects
> using an "Add another " link at the bottom of the object list. There
> is a mockup[2] for this too. It isn't entirely functional yet (I got stuck
> trying to make the new extras actually work) but thanks to some help from
> Brian Rosner and Alex Gaynor, I have a good idea of how to finish it up. So,
> watch for that to drop in the next couple days.
>
> Also, thanks for all the feedback on foreign key autocomplete. I've put that
> feature on the back burner in the interest of tackling inlines first, but
> I'll revisit it a little bit later this summer.
>
> Until next week,
> Zain
>
> [1] Selector 
> Inlines:http://media.wilsonminer.com/images/django/related-objects-stacked.gif
> [2] Stacked Inlines with "add" 
> link:http://media.wilsonminer.com/images/django/related-objects-mock.gif
>
> ---
> My GSoC 
> proposal:http://inzain.net/blog/2009/05/django-gsoc-09-admin-ui-improvements/
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Django Developer -- Job in Washington, DC -- Urgent Need

[Alex Gaynor]

On Tue, Jun 16, 2009 at 4:32 PM, Christy  wrote:

>
> I have a Django/Python/Perl Developer position that I'm working on and
> have had a heck of a time finding anyone who is familiar with Django.
> Any help would be appreciated and if you know of anyone who is using
> Django, I'd love to speak with them.
>
> Perks of the job:
> 50% work from home / 50% work in office in downtown DC
> Using new technologies
> Exciting and stable client
>
> Responsibilities:
> Develop a web content management and publishing system for high
> profile websites in a Linux/Python/Django environment.
>
> Requirements:
> Django (1.0 or higher)
> Python (2.5 or 2.6)
> Linux
> HTML, CSS, Javascript
> PostgreSQL (or MySQL) and SQL
>
> Preferred:
> Perl (5.8)
> Agile
> Vignette Content Management System
>
> ANY help would be wonderful...Thanks to everyone!!
>
> Christy Rogers
> christy.rog...@clovisgroup.com
>
> >
>
The django-developers mailing list is for the development of django itself,
not development with Django.  Please use either the django-users mailing
list, or a site like djangogigs.com

Alex

-- 
"I disapprove of what you say, but I will defend to the death your right to
say it." --Voltaire
"The people's good is the highest law."--Cicero

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Django Developer -- Job in Washington, DC -- Urgent Need

[Christy]

I have a Django/Python/Perl Developer position that I'm working on and
have had a heck of a time finding anyone who is familiar with Django.
Any help would be appreciated and if you know of anyone who is using
Django, I'd love to speak with them.

Perks of the job:
50% work from home / 50% work in office in downtown DC
Using new technologies
Exciting and stable client

Responsibilities:
Develop a web content management and publishing system for high
profile websites in a Linux/Python/Django environment.

Requirements:
Django (1.0 or higher)
Python (2.5 or 2.6)
Linux
HTML, CSS, Javascript
PostgreSQL (or MySQL) and SQL

Preferred:
Perl (5.8)
Agile
Vignette Content Management System

ANY help would be wonderful...Thanks to everyone!!

Christy Rogers
christy.rog...@clovisgroup.com

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: append_slash alternative: remove_slash

[M. N. Islam Shihan]

???

On Jun 17, 2009, at 2:27 AM, Hanne Moa  wrote:

>
> On Tue, Jun 16, 2009 at 22:08, M. N. Islam  
> Shihan wrote:
>> I think another toggle flag ENABLE_REMOVE_SLASH_MODE (or any other
>> appropriate name) can be added to the settings.py and setting that
>> tlag to true will alter the existing APPEND_SLASH flag to be treated
>> as prposed REMOVE_SLASH setting and act accordingly. In this way the
>> existing APPEND_SLASH will act like a tristate variable to dictate  
>> url
>> resolver to append slash (APPEND_SLASH true, ENABLE_REMOVE_SLASH_MODE
>> false), do nothing (APPEND_SLASH false, ENABLE_REMOVE_SLASH_MODE  
>> false
>> and APPEND_SLASH false, ENABLE_REMOVE_SLASH_MODE true)  and remove
>> slash (APPEND_SLASH true, ENABLE_REMOVE_SLASH_MODE true). In all  
>> cases
>> the extra slashes should be removed anyway.
>
> And I want the bikeshed to be painted blue with yellow stars on.
>
>
> HM
>
> >

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Focusing on inlines this week

[patrickk]

@zain: awesome ... definitely looking forward to that.


On 15 Jun., 09:44, Zain Memon  wrote:
> Yeah, I've been keeping a close eye on grappelli -- you guys have done some
> really cool stuff. I plan on refactoring the ordering APIs to make it
> possible to preserve reordering on errors. That's my next task :)
> Zain
>
> On Fri, Jun 12, 2009 at 1:34 AM, patrickk  wrote:
>
> > if you like to implement reordering inlines (as outlined in wilsons
> > graphic for stacked inlines), you might wanna consider this:
> > in case of an error, the reordering should be preserved (of course).
> > as far as I know, this is currently not possible with the way django
> > handles formsets.
>
> > it´d be absolutely awesome to have this feature though ...
>
> > we´ve done something similar with grappelli (using jquery):
> >http://code.google.com/p/django-grappelli/wiki/inlinemodeladminoptions
>
> > thanks,
> > patrick
>
> > On 9 Jun., 14:16, Renato Garcia Pedigoni 
> > wrote:
> > > Great!
> > > I agree with you that selector inline should not replace stacked
> > > inlines. Keep up the good work!
>
> > > On Tue, Jun 9, 2009 at 8:51 AM, Philip Roberts <
> > latentf...@googlemail.com>wrote:
>
> > > > Hi Zain,
>
> > > > Great project you've got there, looking forward to seeing more of what
> > you
> > > > get up to.
>
> > > > Phil
>
> > > --
> > > Atenciosamente,
> > > Renato Garcia Pedigoni
>
>
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Date parsing in DateField

[Ian Clelland]

>
> If we can hold off until that is a dependency of Django, then the code will
> be quite pleasant to implement. Before then, it will likely end up as an
> ugly hack, probably involving building and compiliing regexes at run-time to
> match whatever is in DATE_FORMAT.
>

Never mind that; in 2.3, the code is almost as simple -- and forwards
compatible, too:

import datetime
import time

def parse_date(value):
try:
return datetime.date(*time.strptime(value,settings.DATE_FORMAT)[:3])
except ValueError:
return False

It is probably worth discussing, though, whether the output and input date
formats should always be the same, or if there is value in letting them
differ (especially if someone has set DATE_FORMAT to something like '%b %d,
%Y AD'). There may even be output formats that are not usable as input
formats at all.

Perhaps a DATE_INPUT_FORMAT setting, which defaults if unset to DATE_FORMAT,
would be more appropriate.

-- 
Regards,
Ian Clelland


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: append_slash alternative: remove_slash

[Hanne Moa]

On Tue, Jun 16, 2009 at 22:08, M. N. Islam Shihan wrote:
> I think another toggle flag ENABLE_REMOVE_SLASH_MODE (or any other
> appropriate name) can be added to the settings.py and setting that
> tlag to true will alter the existing APPEND_SLASH flag to be treated
> as prposed REMOVE_SLASH setting and act accordingly. In this way the
> existing APPEND_SLASH will act like a tristate variable to dictate url
> resolver to append slash (APPEND_SLASH true, ENABLE_REMOVE_SLASH_MODE
> false), do nothing (APPEND_SLASH false, ENABLE_REMOVE_SLASH_MODE false
> and APPEND_SLASH false, ENABLE_REMOVE_SLASH_MODE true)  and remove
> slash (APPEND_SLASH true, ENABLE_REMOVE_SLASH_MODE true). In all cases
> the extra slashes should be removed anyway.

And I want the bikeshed to be painted blue with yellow stars on.


HM

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Date parsing in DateField

[Ian Clelland]

On Tue, Jun 16, 2009 at 1:52 AM, Michael Anckaert  wrote:

>
> Currently the code is messy to say the least, currently supported
> DATE_FORMAT:
> %d-%m-%Y  16-06-2009
> %Y-%m-%d  2009-06-16
> And all variants where there are one or two day/month digits and/or the -
> delimiter is a /
>
> I intend to make it compatible with all possible DATE_FORMAT options.
>

With Python 2.5, the code for this should be as simple as:
def parse_date(value):
try:
return datetime.datetime.strptime(value, settings.DATE_FORMAT)
except ValueError:
return False

If we can hold off until that is a dependency of Django, then the code will
be quite pleasant to implement. Before then, it will likely end up as an
ugly hack, probably involving building and compiliing regexes at run-time to
match whatever is in DATE_FORMAT.

-- 
Regards,
Ian Clelland


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: append_slash alternative: remove_slash

[M. N. Islam Shihan]

I think another toggle flag ENABLE_REMOVE_SLASH_MODE (or any other  
appropriate name) can be added to the settings.py and setting that  
tlag to true will alter the existing APPEND_SLASH flag to be treated   
as prposed REMOVE_SLASH setting and act accordingly. In this way the  
existing APPEND_SLASH will act like a tristate variable to dictate url  
resolver to append slash (APPEND_SLASH true, ENABLE_REMOVE_SLASH_MODE  
false), do nothing (APPEND_SLASH false, ENABLE_REMOVE_SLASH_MODE false  
and APPEND_SLASH false, ENABLE_REMOVE_SLASH_MODE true)  and remove  
slash (APPEND_SLASH true, ENABLE_REMOVE_SLASH_MODE true). In all cases  
the extra slashes should be removed anyway.

Cheers
Shihan

On Jun 16, 2009, at 6:55 PM, Justin end Myers   
wrote

>
> On Jun 16, 3:49 am, Ivan Sagalaev  wrote:
>> Indeed I don't really want to discuss the proposal itself (I don't
>> really care of the outcome since you don't propose to remove
>> APPEND_SLASH altogether). I was just trying to show that bashing some
>> people's preference doesn't help in making a point. Feel free to  
>> ignore
>> the advice.
>
> Which hopefully will bring us back on topic: Regardless of our
> individual feelings on the trailing-slash holy war here, Patrick said
> it best--let's have a way to get rid of the URLs we agree are bad
> (multiple consecutive slashes) and a way to choose whether we want to
> append or remove the trailing slash.
>
> The whole point is consistency in order to help keep our search
> results and rankings in line--which I think we can all agree is a Good
> Thing. Anyone interested in working on it?
> >

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: append_slash alternative: remove_slash

[Luke Plant]

On Sunday 14 June 2009 06:12:32 donquixote wrote:

> Nice (i):
> http://mysite.org/members/emil
> http://mysite.org/members/emil/contact
>
> Not nice (ii):
> http://mysite.org/members/emil/
> http://mysite.org/members/emil/contact/

You have some problems:

1) All contrib apps, and many others, put a slash at end of the URL 
conf regexes.  This means that without APPEND_SLASH = True, you will 
get 404s for e.g. /admin/foo  which is not very friendly behaviour.

2) Having more than one convention is not going to be popular - 
especially as django apps are often designed to be pluggable.  
Inconsistency here would be a pain in neck

3) Changing these existing apps to make the trailing slash optional 
would be a *very* big task, especially when you use relative URLs like 
href="../../somewhere/else/".  If the current URL doesn't have a 
trailing slash, then those relative URLs will be broken.  In theory, 
this should be fixed by use URL reversing correctly, but there isn't 
even a fully capable solution in trunk yet (I believe the current 
status is some design decisions need to be made with regards to the 
case where you have multiple instances of the same app, I might be 
wrong).  Anyway, there are *many* instances of relative URLs still in 
the Django code base.  And I think it affects CSS too (which is not so 
easily addressed as template or Python code).

Seeing as some people actually prefer the trailing slash, I think it 
is fair to say that you are fighting a losing battle.

Luke

-- 
"If we could just get everyone to close their eyes and visualise world
 peace for an hour, imagine how serene and quiet it would be until the
 looting started" -- Anon

Luke Plant || http://lukeplant.me.uk/


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: append_slash alternative: remove_slash

[Adys]

I have never messed with this part of Django but I'm up for a try; by
the end of this month I'll have some time off to work on it if no one
else is able to. Feel free to file a ticket.

On Jun 16, 3:55 pm, Justin Myers  wrote:
> On Jun 16, 3:49 am, Ivan Sagalaev  wrote:
>
> > Indeed I don't really want to discuss the proposal itself (I don't
> > really care of the outcome since you don't propose to remove
> > APPEND_SLASH altogether). I was just trying to show that bashing some
> > people's preference doesn't help in making a point. Feel free to ignore
> > the advice.
>
> Which hopefully will bring us back on topic: Regardless of our
> individual feelings on the trailing-slash holy war here, Patrick said
> it best--let's have a way to get rid of the URLs we agree are bad
> (multiple consecutive slashes) and a way to choose whether we want to
> append or remove the trailing slash.
>
> The whole point is consistency in order to help keep our search
> results and rankings in line--which I think we can all agree is a Good
> Thing. Anyone interested in working on it?
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: append_slash alternative: remove_slash

[Justin Myers]

On Jun 16, 3:49 am, Ivan Sagalaev  wrote:
> Indeed I don't really want to discuss the proposal itself (I don't
> really care of the outcome since you don't propose to remove
> APPEND_SLASH altogether). I was just trying to show that bashing some
> people's preference doesn't help in making a point. Feel free to ignore
> the advice.

Which hopefully will bring us back on topic: Regardless of our
individual feelings on the trailing-slash holy war here, Patrick said
it best--let's have a way to get rid of the URLs we agree are bad
(multiple consecutive slashes) and a way to choose whether we want to
append or remove the trailing slash.

The whole point is consistency in order to help keep our search
results and rankings in line--which I think we can all agree is a Good
Thing. Anyone interested in working on it?
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Date parsing in DateField

[Michael Anckaert]

Hello everyone,

I recently stumbled on a problem (at least for me) that you can't pass any
string to a datefield and have it parsed as a correct date. The current
implementation in SVN expects a string in the format of -MM-DD.
There is however a wonderful option in settings.py called DATE_FORMAT. The
attached patch changes the django/db/models/fields/__init__.py file so that
the DateField accepts strings in the format defined in settings.DATE_FORMAT.


Currently the code is messy to say the least, currently supported
DATE_FORMAT:
%d-%m-%Y  16-06-2009
%Y-%m-%d  2009-06-16
And all variants where there are one or two day/month digits and/or the -
delimiter is a /

I intend to make it compatible with all possible DATE_FORMAT options.

-- 
Met vriendelijke groeten,
Kind regards,
Michael Anckaert
Sinax Consultant
+32 473 779 135
http://www.sinax.be

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Index: django/db/models/fields/__init__.py
===
--- django/db/models/fields/__init__.py	(revision 11012)
+++ django/db/models/fields/__init__.py	(working copy)
@@ -446,8 +446,37 @@
 defaults.update(kwargs)
 return super(CommaSeparatedIntegerField, self).formfield(**defaults)
 
-ansi_date_re = re.compile(r'^\d{4}-\d{1,2}-\d{1,2}$')
+def parse_date(value):
+	"""
+		Parses a string to a date according to the Django setting DATE_FORMAT
+		Currently supported DATE_FORMAT:
+			%d-%m-%Y	16-06-2009
+			%Y-%m-%d	2009-06-16
+			And all variants where there is one or two day/month digits and/or the - delimiter is a /
+	"""
+	DATE_FORMAT = settings.DATE_FORMAT
+	if DATE_FORMAT == "%d-%m-%Y":
+		if re.compile(r'^\d{1,2}-\d{1,2}-\d{4}$').match(value):
+			day, month, year = map(int, value.split("-"))
+			return datetime.date(year, month, day)
 
+	if DATE_FORMAT == "%d/%m/%Y":
+		if re.compile(r'^\d{1,2}/\d{1,2}/\d{4}$').match(value):
+			day, month, year = map(int, value.split("/"))
+			return datetime.date(year, month, day)
+
+	if DATE_FORMAT == "%Y-%m-%d":
+		if re.compile(r'^\d{4}-\d{1,2}-\d{1,2}$').match(value):
+			year, month, day = map(int, value.split("-"))
+			return datetime.date(year, month, day)
+
+	if DATE_FORMAT == "%Y/%m/%d":
+		if re.compile(r'^\d{4}/\d{1,2}/\d{1,2}$').match(value):
+			year, month, day = map(int, value.split("/"))
+			return datetime.date(year, month, day)
+
+	return False
+
 class DateField(Field):
 empty_strings_allowed = False
 def __init__(self, verbose_name=None, name=None, auto_now=False, auto_now_add=False, **kwargs):
@@ -462,27 +491,20 @@
 return "DateField"
 
 def to_python(self, value):
-if value is None:
-return value
-if isinstance(value, datetime.datetime):
-return value.date()
-if isinstance(value, datetime.date):
-return value
+if value is None:
+		return value
+if isinstance(value, datetime.datetime):
+		return value.date()
+if isinstance(value, datetime.date):
+		return value
 
-if not ansi_date_re.search(value):
-raise exceptions.ValidationError(
-_('Enter a valid date in -MM-DD format.'))
-# Now that we have the date string in -MM-DD format, check to make
-# sure it's a valid date.
-# We could use time.strptime here and catch errors, but datetime.date
-# produces much friendlier error messages.
-year, month, day = map(int, value.split('-'))
-try:
-return datetime.date(year, month, day)
-except ValueError, e:
-msg = _('Invalid date: %s') % _(str(e))
-raise exceptions.ValidationError(msg)
+d = parse_date(value)
+if not d:
+		raise exceptions.ValidationError(
+_('Enter a valid date in the format you defined in settings.py.'))
 
+return d
+
 def pre_save(self, model_instance, add):
 if self.auto_now or (self.auto_now_add and add):
 value = datetime.datetime.now()

Why is the call for not in base.py

[Refael Ackermann]

I'm investigating middleware behavior and found that the following
code:

response = self.get_response(request)

# Apply response middleware
for middleware_method in self._response_middleware:
response = middleware_method(request, response)


Is duplicated verbatim in wsgi.py & modpython.py (not in
profiler_hotspot.py), and even in test/client.py

Can I refactor this into base.get_response

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: append_slash alternative: remove_slash

[Ivan Sagalaev]

Adys wrote:
> And please don't speak "on behalf" of other Django developers.

I don't. It's a simple matter of fact that APPEND_SLASH defaults to True 
and CommonMiddleware is installed be default and djangoproject.com uses 
trailing slash and first four sites from http://djangosites.org/ also do 
this. And though I can't find it by now, I remember that back in 2005 
somewhere in Django FAQ there was a personal reference from core 
developers that they prefer URLs with slashes.

> If you indeed cannot bear yourself to conveniently
> discuss something, your post was not necessary in any way.

Indeed I don't really want to discuss the proposal itself (I don't 
really care of the outcome since you don't propose to remove 
APPEND_SLASH altogether). I was just trying to show that bashing some 
people's preference doesn't help in making a point. Feel free to ignore 
the advice.

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: append_slash alternative: remove_slash

[Adys]

On Jun 16, 11:27 am, Ivan Sagalaev  wrote:
> Sorry for interrupting your lively conversation gentlemen... If you
> allow me to give an advice then your proposal will look better without
> constantly referring to one trailing slash with disparaging adjectives
> (such as "unclean"). Most of Django world actually prefers this variant.
> Which is not a way of saying that the proposal is useless, I just can't
> bear myself to discuss things from my supposedly "unclean" position.

Wow, hold your fire there. I said "unclean" because the proposed
setting would "clean up" the url.
And please don't speak "on behalf" of other Django developers. I
didn't aim anything at anyone, the entire point is to have an
additional setting. If you indeed cannot bear yourself to conveniently
discuss something, your post was not necessary in any way.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: append_slash alternative: remove_slash

[Ivan Sagalaev]

Adys wrote:
> Clean:
> http://example.com/foo/bar
> 
> Unclean
> http://example.com/foo/bar/
> http://example.com/foo///bar
> http://example.com///foo//bar///

Sorry for interrupting your lively conversation gentlemen... If you 
allow me to give an advice then your proposal will look better without 
constantly referring to one trailing slash with disparaging adjectives 
(such as "unclean"). Most of Django world actually prefers this variant. 
Which is not a way of saying that the proposal is useless, I just can't 
bear myself to discuss things from my supposedly "unclean" position.

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---