Re: Session/cookie based messages (#4604)

2009-12-02 Thread Alex Gaynor 
On Thu, Dec 3, 2009 at 12:58 AM, Tobias McNulty  wrote:
>
>
> On Tue, Dec 1, 2009 at 4:35 PM, Luke Plant  wrote:
>>
>> I just converted some code, and the API seems good to me.  I had one
>> issue, which was the fact that I had some code which only had access
>> to the User object, and not the request object, which had to be re-
>> plumbed.  The only place this change will be an issue is where it is
>> difficult to do that (e.g. if your code is being called from somewhere
>> else which you can't change).  There is no reason this should hold us
>> back - storing messages on the User is really a hack, and if people
>> have a problem with not being able to do it any more (i.e. in Django
>> 1.4), they can use other hacks like storing the request in threadlocal
>> storage.
>
> *gasp* Did I really just hear a core committer condoning threadlocals?
> Storing messages on the user was bad, but not that bad.  :)
>
>>
>> The simplest solution is to catch the exception in the generic views.
>> Another option is to add a 'fail_silently' keyword argument,
>> defaulting to False, like the mail sending API. It would need to be
>> added to all the shortcut functions, and used in the generic views and
>> anywhere that you cannot rely on there being a current authenticated
>> User.  Docs should include something about it being intended for re-
>> usable apps.
>
> Good catch.  fail_silently sounds good to me.  I'll add.
>
> Tobias
> --
> Tobias McNulty
> Caktus Consulting Group, LLC
> P.O. Box 1454
> Carrboro, NC 27510
> (919) 951-0052
> http://www.caktusgroup.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-develop...@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.
>

I haven't been paying as much attention to this thread as I should be
:(.  However, I just read through the diff that was uploaded, and I'm
curious why the decision to go with functions with APIs like
messages.info(request, msg).  Instead of request.messages.info(msg).
The latter reads far better to me.

Thanks,
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
"Code can always be simpler than you think, but never as simple as you
want" -- Me

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: Session/cookie based messages (#4604)

2009-12-02 Thread Tobias McNulty 
Latest patch, including fail_silently, is up for review:

http://code.djangoproject.com/attachment/ticket/4604/django-contrib-messages-e4da706e1152.diff

Cheers,
Tobias

2009/12/3 Tobias McNulty 

> The simplest solution is to catch the exception in the generic views.
>> Another option is to add a 'fail_silently' keyword argument,
>> defaulting to False, like the mail sending API. It would need to be
>> added to all the shortcut functions, and used in the generic views and
>> anywhere that you cannot rely on there being a current authenticated
>> User.  Docs should include something about it being intended for re-
>> usable apps.
>>
>
> Good catch.  fail_silently sounds good to me.  I'll add.
>



-- 
Tobias McNulty
Caktus Consulting Group, LLC
P.O. Box 1454
Carrboro, NC 27510
(919) 951-0052
http://www.caktusgroup.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-develop...@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: Session/cookie based messages (#4604)

2009-12-02 Thread Tobias McNulty 
On Tue, Dec 1, 2009 at 4:35 PM, Luke Plant  wrote:

> I just converted some code, and the API seems good to me.  I had one
> issue, which was the fact that I had some code which only had access
> to the User object, and not the request object, which had to be re-
> plumbed.  The only place this change will be an issue is where it is
> difficult to do that (e.g. if your code is being called from somewhere
> else which you can't change).  There is no reason this should hold us
> back - storing messages on the User is really a hack, and if people
> have a problem with not being able to do it any more (i.e. in Django
> 1.4), they can use other hacks like storing the request in threadlocal
> storage.
>

*gasp* Did I really just hear a core committer condoning threadlocals?
Storing messages on the user was bad, but not that bad.  :)


> The simplest solution is to catch the exception in the generic views.
> Another option is to add a 'fail_silently' keyword argument,
> defaulting to False, like the mail sending API. It would need to be
> added to all the shortcut functions, and used in the generic views and
> anywhere that you cannot rely on there being a current authenticated
> User.  Docs should include something about it being intended for re-
> usable apps.
>

Good catch.  fail_silently sounds good to me.  I'll add.

Tobias
-- 
Tobias McNulty
Caktus Consulting Group, LLC
P.O. Box 1454
Carrboro, NC 27510
(919) 951-0052
http://www.caktusgroup.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-develop...@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: Problem with history view in admin page

2009-12-02 Thread Mario Briggs 
Russ,

I dont agree to the *it works* theory here - Ian rightly said 'If you
ask me,
anybody foolish enough to use a TextField as a primary key deserves
what they get' and you agreed  'Your comment about foolishness is
definitely correct '

Putting it in context, this is in the 'user control area' and the fact
that one can go ahead and change the type in the LogEntry definition
like Helgi did means it not a blockade (though it would be good if
Django got i right first time).

I have another question though but that is due to my lack of wide
usage of Django - so you mentioned that u were scared to make the
changes becuase of problems with migrations - once Helgi makes that
change and the next time he is upgrading to the a higher version of
Django, is there anything he needs to do ?

cheers
Mario

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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 Developed Sprint in Chicago, January 9-10

2009-12-02 Thread Alex Gaynor 
Hello all,

On Janaury 9-10 in Chicago we'll be holding a development sprint for
Django.  This sprint will focus primarily on bugfixing for Django's
upcoming 1.2 release.  No prior experience is needed, there'll be
plenty of people there to help you get started!  More information can
be found here: http://code.djangoproject.com/wiki/Sprint20101Chicago .
 If you're interested/planning on showing up just add yourself to the
list.  Everyblock has graciously offered up their offices for our use.

Hope to see you there,
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
"Code can always be simpler than you think, but never as simple as you
want" -- Me

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: Session/cookie based messages (#4604)

2009-12-02 Thread Tobias McNulty 
Sorry for the wait.  You should have access now.  :)

On Tue, Dec 1, 2009 at 8:26 PM, SmileyChris  wrote:

> I applied and pushed all but your final whitespace revision.
>
> When Tobias reads this thread again, I'm sure he'll give you commit.
> The fail_silently sounds good, and yes these failures were a rather
> big oversight.
>
> On Dec 2, 10:35 am, Luke Plant  wrote:
> > I've been going through the code carefully now, and I've got a bunch
> > of patches, mainly very minor (attached as a mercurial bundle, use "hg
> > in fixes.bundle" to view, or if you give me commit rights to your
> > repository I'll commit directly), and one significant issue:
> >
> > If I read the patch correctly, when a non-authenticated user uses a
> > generic view (create/update/delete), they will get a failure if the
> > messages framework is not installed. This is a big backwards
> > incompatibility.
>
> --
>
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-develop...@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.
>
>
>


-- 
Tobias McNulty
Caktus Consulting Group, LLC
P.O. Box 1454
Carrboro, NC 27510
(919) 951-0052
http://www.caktusgroup.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-develop...@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 needs for normal sequence of handlers for request processing

2009-12-02 Thread serg 

it's last:

I don't know how to provide order of processing outside middlewares...
i stopped on this:

settings.py:

MIDDLEWARE_CLASSES = (
'django.middleware.common.CommonMiddleware',
'django.contrib.sessions.middleware.SessionMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
'middleware.handlers.Handler',
)

middleware handlers:

import re
from django.http import HttpResponseRedirect

class Handler(object):
def process_request(self, request, *args, **kwargs):
self.__class__.handlers = []
def process_view(self, request, view_func, view_args,
view_kwargs):
if 'h_LoginRequired' in view_kwargs:
res = self.LoginRequired(request, view_kwargs
['h_LoginRequired'])
if res is not None:
return res
del view_kwargs['h_LoginRequired']
if 'h_PermissionRequired' in view_kwargs:
res = self.PermissionRequired(request, view_kwargs
['h_PermissionRequired'])
if res is not None:
return res
del view_kwargs['h_PermissionRequired']
''' add your handlers here:
def myHandler(self, request, *args, **kwargs):
if all_is_okay():
return None
return HttpResponseRedirect('/a_bad_result_page.html') #
for example
'''
def LoginRequired(self, request, *args, **kwargs):
if request is not None:
if request.user is not None and
request.user.is_authenticated():
return None
return HttpResponseRedirect('/login.html')
def PermissionRequired(self, request, *args, **kwargs):
# check permissions for access to '^members/account/' area
return None

urls.py:
(r'^members/', include('members.urls'), {'h_LoginRequired':{}}),

members.urls:
(r'^private/', include('members.private.urls'), {
  'h_PermissionRequired':{
  'handler_arg_name1':'handler_value1',
  'handler_arg_name2':'handler_value2',
  },
  'view_arg_name1':'view_value1',
  'view_arg_name2':'view_value2',
  }
),

development process:
1. make new handler in middleware.Handler
2. add handler processing to Handler. process_view(..)
3. in urls.py create "h_HandlerName" view_param

i've no idea normal handler conveyer about

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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.