Unicode SlugField

[Ali Nikneshan]

Hi,
There is a Historical 
threadabout
 allowing Unicode characters in  SlugField. I also find a Bug report 
#16501  which is promised for 
this feature in 1.5 or 1.6.
So what's the plan? will we have this feature in 1.5? Or there is 
still ambition about the need or support of browser yet? 
Thanks
Ali


-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/DL46byGYM8QJ.
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: Unicode SlugField

[Florian Apolloner]

Hi,

it surely won't change in 1.5 since we already released an alpha.

Cheers,
Florian

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/o2aDF3Mef9kJ.
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.

Weird characters in HTTP_USER_AGENT

[Martin Tiršel]

Hi all, 

some days ago I began to store user agent strings but found, that there is 
at least one client with some weird characters causing the SQL query to 
fail. In the txt logs I have:

`Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; IS<8a> Sokolnice; 
IS<8a> Sokolnice)`

this is my code in my manager:

return self.create(
cookie_value=uuid.uuid4().hex,
visitor=visitor,
user_agent=request.META['HTTP_USER_AGENT'][:500]
)

creates this query (taken from tcpdump):

INSERT INTO \"tracking_trackingcookie\" (\"cookie_value\", \"visitor_id\", 
\"created\", \"user_agent\") VALUES ('546eea39a39645819441de03703d71de', 
2927305, '2012-11-01 13:39:04.218208', 'Mozilla/4.0 (compatible; MSIE 7.0; 
Windows NT 5.1; IS\x8a Sokolnice; IS\x8a Sokolnice)') RETURNING 
\"tracking_trackingcookie\".\"id\"

Database answer is:

2012-11-01 14:08:47.558 
CET,"xxx","xxx",16405,"192.168.1.4:33564",50926467.4015,2108568,"idle in 
transaction (aborted)",2012-11-01 13:00:39 CET,4/0,0,ERROR,22021,"invalid 
byte sequence for encoding ""UTF8"": 0x8a",""


So, my question is, should not Django solve any issues with characters in 
HTTP headers so I can rely on it and store it safely to DB? If not, what do 
you suggest to do with such user agent strings? DB is set to UTF8.

I am using:

Django==1.4
psycopg2==2.4.1

Postgres 9.1.6


Thanks,
Martin

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/1xSjNAy8UfQJ.
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: Unicode SlugField

[Russell Keith-Magee]

On Thu, Nov 1, 2012 at 8:27 PM, Florian Apolloner wrote:

> Hi,
>
> it surely won't change in 1.5 since we already released an alpha.
>
> That's incorrect -- it's still possible. Alpha is the freeze for "big"
features. Little features can still be added up till the release of the
beta. A minor enhancement to an existing field would definitely fall under
the category of a minor feature.

However, this all hinges on someone getting:

 1) consensus on a design,
 2) a commit-ready patch that implements that design.

Reading the ticket, we haven't yet achieved (1). The most recent comment
was 9 months ago, and hasn't been followed up. For the record, that comment
doesn't "promise" anything -- it's just saying that if a change is going to
happen, it couldn't happen any sooner than 1.5 (since 1.4 was already out,
and a change like this *won't* be back ported).

So - if you want this, now would be a very good time to do exactly what the
ticket says, and lead the discussion advocating it.

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: Unicode SlugField

[Claude Paroz]

Le jeudi 1 novembre 2012 14:32:12 UTC+1, Russell Keith-Magee a écrit :
>
>
> However, this all hinges on someone getting:
>
>  1) consensus on a design,
>  2) a commit-ready patch that implements that design.
>
> Reading the ticket, we haven't yet achieved (1). The most recent comment 
> was 9 months ago, and hasn't been followed up. For the record, that comment 
> doesn't "promise" anything -- it's just saying that if a change is going to 
> happen, it couldn't happen any sooner than 1.5 (since 1.4 was already out, 
> and a change like this *won't* be back ported).
>
> So - if you want this, now would be a very good time to do exactly what 
> the ticket says, and lead the discussion advocating it.
>

For me, changing the outcome of validate_slug is not an option, like Paul 
wrote on the ticket. I'd suggest:
  a) creating a new validate_uslug validator (better name anyone?)
  b) allowing a custom validator to be passed to the SlugField constructor

Claude

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/bSf-Oj3VOH0J.
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: Class based views: A standard hook for http-method-independent code (and a proposal for an init() method)

[Aaron Merriam]

Just wanted to put my +1 into this thread.  I've been fighting for a clean 
way to implement permissions in class based views and the 'init' method 
would help my implementation be a lot more DRY.

On Wednesday, October 31, 2012 12:42:33 PM UTC-6, Jordan Hagan wrote:
>
> Diedreik,
>
> Thanks for your comments - your solution seems similar to the one proposed 
> by Meshy unless I'm missing something (https://gist.github.com/1957251). 
> It is good to see multiple people coming up with the same solution to the 
> issue independently though as that to me is an indication that we're moving 
> in the right direction.
>
> Meshy,
>
> Thanks for the link - the django-braces project looks useful - I'll 
> probably start using that.
>
> I would love to get some input from a core developer (or two) on this to 
> see where they stand. From where I'm sitting there seems to be a number of 
> people working around this problem in more or less the same manner, and 
> most of the arguments against haven't taken into 
> consideration compatibility with other mixins, already existing class 
> methods, etc.
>
> I would be happy to put together a patch in a ticket on trac and do any 
> other grunt work required to make this happen.
>
> Cheers,
> Jordan
>
> On Wednesday, 31 October 2012 22:57:28 UTC+13, Meshy wrote:
>>
>> Marc and I have been using a mixin to override `dispatch()` with this 
>> functionality. He has an ongoing pull request on 
>> django-braceswith the code. 
>> I hope this can be useful to some of you.
>>
>> Meshy.
>>
>> On Wednesday, October 31, 2012 9:49:26 AM UTC, Diederik van der Boor 
>> wrote:
>>>
>>> Hi,
>>>
>>> Please allow me to add my €0.02.
>>> In a large project I've experienced a similar issue; and we solved it in 
>>> a slightly different way.
>>> What we also noticed was:
>>> - overriding dispatch(), get() or post() wasn't good enough anymore.
>>> - the views need some initialization moment before their workflow (in 
>>> get/post of the base classes) start.
>>>
>>> What we ended up with is this base class (simplified a bit):
>>> https://gist.github.com/3985939
>>>
>>> *I seriously propose having such init() function in the Django views.*
>>> Mind you, that took a heated debate in the organization I was contacted 
>>> for, so please allow me to explain to context here.
>>> I think we've found a missing cornerstone in the way the class based 
>>> views are structured, and there is an easy fix.
>>>
>>> *What is the problem with overriding dispatch()?*
>>> When overriding dispatch(), get() or post() the flow is always:
>>>
>>> def dispatch(self, request, *args, **kwargs):
>>> # my code here.
>>> return super(…).dispatch(request, *args, **kwargs)
>>>
>>> The same also applies to get() and post().
>>> In other words, the last deriving class on top of the inheritance chain 
>>> is always initializing first before it's base classes.
>>> It can't rely on a base class to do some initialization.
>>>
>>> With our permission check in the base class' dispatch() method, anything 
>>> deriving from that effectively
>>> couldn't override dispatch() anymore because that would run before the 
>>> permission check.
>>>
>>> *How does the init method fix this?*
>>> By doing a self.init() in the top-most dispatch() method, each class in 
>>> the inheritance chain has a chance to fetch the objects it needs to have.
>>>
>>> That code can be written as:
>>>
>>> def init(self):
>>> super(..).init()
>>> # my code here.
>>>
>>> Now, the base class can initialize, then the deriving class.
>>> With a larger inheritance chain, this behavior becomes crucial.
>>> Each class can build upon what the other has prepared already.
>>>
>>>
>>> All of a sudden, we could do things like this:
>>>
>>> class PhotoListView(TabbedListView):
>>> """
>>> Contents of an photo album; a list of photo's.
>>> """
>>> model = Photo
>>>
>>> template_name = "photoalbum_album.html"
>>> permission_class = permissions.PhotoAlbumViewPermission
>>>
>>> def init(self):
>>> super(PhotoListView, self).init()
>>> self.photoalbum = get_object_or_404(PhotoAlbum, 
>>> pk=self.kwargs['pk'])  # parent object that filters the list
>>>
>>> def get_queryset(self):
>>> return super(PhotoListView, 
>>> self).get_queryset().in_album(self.photoalbum)
>>>
>>> def get_context_data(self, **kwargs):
>>> context = super(PhotoListView, self).get_context_data(**kwargs)
>>> context['photoalbum'] = self.photoalbum
>>> context['can_delete'] = self.is_authorized_for(PhotoDeleteView)
>>> return context
>>>
>>> This is a list view for photo's, and it's limited to a current photo 
>>> album.
>>> The alternative is making a DetailView, and putting the photo's 
>>> somewhere in get_context_data() and thereby loose what the list view 
>>> has to offer.
>>> Now we can just state it's a list view (which it is), and introduce the 
>>> filt

Re: Class based views: A standard hook for http-method-independent code (and a proposal for an init() method)

[Andre Terra]

At first I wasn't sure about this hook, but after working with permissions
in CBVs I can see how this would allow for much simpler code, especially
when you're implementing a lot of subclassing. I tend to get carried away
in writing mixins and base classes for my views, so yeah, I'm +1 on this
too.

Cheers,
AT

-- Sent from my phone, please excuse any typos. --
On Nov 1, 2012 12:31 PM, "Aaron Merriam"  wrote:

> Just wanted to put my +1 into this thread.  I've been fighting for a clean
> way to implement permissions in class based views and the 'init' method
> would help my implementation be a lot more DRY.
>
> On Wednesday, October 31, 2012 12:42:33 PM UTC-6, Jordan Hagan wrote:
>>
>> Diedreik,
>>
>> Thanks for your comments - your solution seems similar to the one
>> proposed by Meshy unless I'm missing something (https://gist.github.com/*
>> *1957251 ). It is good to see multiple
>> people coming up with the same solution to the issue independently though
>> as that to me is an indication that we're moving in the right direction.
>>
>> Meshy,
>>
>> Thanks for the link - the django-braces project looks useful - I'll
>> probably start using that.
>>
>> I would love to get some input from a core developer (or two) on this to
>> see where they stand. From where I'm sitting there seems to be a number of
>> people working around this problem in more or less the same manner, and
>> most of the arguments against haven't taken into
>> consideration compatibility **with other mixins, already existing class
>> methods, etc.
>>
>> I would be happy to put together a patch in a ticket on trac and do any
>> other grunt work required to make this happen.
>>
>> Cheers,
>> Jordan
>>
>> On Wednesday, 31 October 2012 22:57:28 UTC+13, Meshy wrote:
>>>
>>> Marc and I have been using a mixin to override `dispatch()` with this
>>> functionality. He has an ongoing pull request on 
>>> django-braceswith the 
>>> code. I hope this can be useful to some of you.
>>>
>>> Meshy.
>>>
>>> On Wednesday, October 31, 2012 9:49:26 AM UTC, Diederik van der Boor
>>> wrote:

 Hi,

 Please allow me to add my €0.02.
 In a large project I've experienced a similar issue; and we solved it
 in a slightly different way.
 What we also noticed was:
 - overriding dispatch(), get() or post() wasn't good enough anymore.
 - the views need some initialization moment before their workflow (in
 get/post of the base classes) start.

 What we ended up with is this base class (simplified a bit):
 https://gist.github.com/**3985939 

 *I seriously propose having such init() function in the Django views.*
 Mind you, that took a heated debate in the organization I was contacted
 for, so please allow me to explain to context here.
 I think we've found a missing cornerstone in the way the class based
 views are structured, and there is an easy fix.

 *What is the problem with overriding dispatch()?*
 When overriding dispatch(), get() or post() the flow is always:

 def dispatch(self, request, *args, **kwargs):
 # my code here.
 return super(…).dispatch(request, *args, **kwargs)

 The same also applies to get() and post().
 In other words, the last deriving class on top of the inheritance chain
 is always initializing first before it's base classes.
 It can't rely on a base class to do some initialization.

 With our permission check in the base class' dispatch()
 method, anything deriving from that effectively
 couldn't override dispatch() anymore because that would run before the
 permission check.

 *How does the init method fix this?*
 By doing a self.init() in the top-most dispatch() method, each class in
 the inheritance chain has a chance to fetch the objects it needs to have.

 That code can be written as:

 def init(self):
 super(..).init()
 # my code here.

 Now, the base class can initialize, then the deriving class.
 With a larger inheritance chain, this behavior becomes crucial.
 Each class can build upon what the other has prepared already.


 All of a sudden, we could do things like this:

 class PhotoListView(TabbedListView):
 """
 Contents of an photo album; a list of photo's.
 """
 model = Photo

 template_name = "photoalbum_album.html"
 permission_class = permissions.**PhotoAlbumViewPermission

 def init(self):
 super(PhotoListView, self).init()
 self.photoalbum = get_object_or_404(PhotoAlbum,
 pk=self.kwargs['pk'])  # parent object that filters the list

 def get_queryset(self):
 return super(PhotoListView, self).get_queryset().in_album(**
 self.photoalbum)

 def get_context

Re: Github tags

[Samus_]

hi, I think that's great :) in the meantime could you please indicate the 
commits that will be tagged? thanks!

On Monday, October 29, 2012 1:42:19 PM UTC-2, Jacob Kaplan-Moss wrote:
>
> Just so y'all know, this is on the todo list. We want to start doing 
> signed tags (something cool that we can do now that we use git), so 
> we've been putting it off until we figure out exactly how to do that 
> (and, more importantly, who should do the signing.) 
>
> Jacob 
>
> On Mon, Oct 29, 2012 at 10:30 AM, Yo-Yo Ma 
> > 
> wrote: 
> > +1 
> > 
> > 
> > On Monday, October 29, 2012 5:18:48 AM UTC-4, Jan Bednařík wrote: 
> >> 
> >> There is also related ticket 
> https://code.djangoproject.com/ticket/19141 
> >> 
> >> Jan 
> >> 
> >> 
> >> On Mon, Oct 29, 2012 at 3:36 AM, Matt Austin  
> >> wrote: 
> >> > Hi, 
> >> > 
> >> > Would it be possible to get tags for 1.3.3, 1.3.4, 1.4.2, and 1.5 
> >> > alpha tagged on the github repository? The tagging seems to have 
> >> > fallen behind with these releases. 
> >> > 
> >> > Thanks, 
> >> > 
> >> > -- 
> >> > Matt 
> >> > 
> >> > -- 
> >> > You received this message because you are subscribed to the Google 
> >> > Groups "Django developers" group. 
> >> > To post to this group, send email to django-d...@googlegroups.com. 
> >> > To unsubscribe from this group, send email to 
> >> > django-develop...@googlegroups.com. 
> >> > For more options, visit this group at 
> >> > http://groups.google.com/group/django-developers?hl=en. 
> >> > 
> > 
> > -- 
> > You received this message because you are subscribed to the Google 
> Groups 
> > "Django developers" group. 
> > To view this discussion on the web visit 
> > https://groups.google.com/d/msg/django-developers/-/qWKMQb_tsmAJ. 
> > 
> > To post to this group, send email to 
> > django-d...@googlegroups.com. 
>
> > To unsubscribe from this group, send email to 
> > django-develop...@googlegroups.com . 
> > For more options, visit this group at 
> > http://groups.google.com/group/django-developers?hl=en. 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/nQP8epTa72EJ.
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.