Re: #6735 -- Class based generic views: call for comment

[Russell Keith-Magee]

On Wed, Oct 6, 2010 at 8:33 AM, Luke Plant  wrote:
> On Tue, 2010-10-05 at 22:29 +0100, I wrote:
>
>> Russell - beware - I think bitbucket has managed to create a very broken
>> clone. I did a fork as well, and both of our repositories are missing
>> thousands of commits.  I can do a pull from django/django and I then get
>> a complete repository which then seems to be compatible with
>> django/django.  I've e-mailed the bitbucket folks, but have left my
>> clone as it is for now to allow them to work out what has gone wrong.
>
> It seems that the clones being created are not corrupted, but bitbucket
> is choosing a 'forkpoint' which means that you get a partial repository.
> You can get a full repository by pulling from django/django and pushing
> back to your clone.  It would be helpful if you did that on your clone
> Russell - at the moment if I do 'hg outgoing freakboy' I get thousands
> of commits that you are missing.

Done.

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-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: Problems with logging and Python 2.4

[Russell Keith-Magee]

Dang - accidentally hit send. Let's try that again.

2010/10/6 Russell Keith-Magee :
> 2010/10/6 Łukasz Rekucki :
>> Hi,
>>
>> I'm getting a whole bunch of errors related to logging on Python 2.4::
>>
>> ERROR: Missing templates are correctly reported by test client
>> --
>> Traceback (most recent call last):
>>  File 
>> "/home/lrekucki/projekty/django/django_trunk/tests/regressiontests/test_client_regress/models.py",
>> line 583, in test_no_404_template
>>    response = self.client.get("/no_such_view/")
>>  File "/home/lrekucki/projekty/django/django_trunk/django/test/client.py",
>> line 298, in get
>>    response = self.request(**r)
>>  File "/home/lrekucki/projekty/django/django_trunk/django/test/client.py",
>> line 238, in request
>>    response = self.handler(environ)
>>  File "/home/lrekucki/projekty/django/django_trunk/django/test/client.py",
>> line 79, in __call__
>>    response = self.get_response(request)
>>  File 
>> "/home/lrekucki/projekty/django/django_trunk/django/core/handlers/base.py",
>> line 139, in get_response
>>    return self.handle_uncaught_exception(request, resolver, sys.exc_info())
>>  File 
>> "/home/lrekucki/projekty/django/django_trunk/django/core/handlers/base.py",
>> line 182, in handle_uncaught_exception
>>    extra={
>>  File "/home/lrekucki/python/plain2.4//lib/python2.4/logging/__init__.py",
>> line 999, in error
>>    apply(self._log, (ERROR, msg, args), kwargs)
>> TypeError: _log() got an unexpected keyword argument 'extra'
>>
>> Sadly, it's true - log functions don't have extra=* in Python 2.4[1].
>> Possible solutions I can see right now:
>>
>>  * revert the logging patch (that would be quite bad)
>>  * try to do some ugly monkey patching to the logging module
>>  * drop Python 2.4 support
>>
>> Opinions ?

I shall now sing a selection of arias from the opera I have written,
entitled "Oh crap and buggery".

:-)

Dropping Python 2.4 would be the easiest solution, but as I've
commented previously, it really isn't an option. I really don't want
to revert logging -- the set of cases where it's useful vastly exceeds
the cases where it isn't.

Monkeypatching isn't a particularly attractive option to me - there's
just too much .

A fourth option would be to include Python's logging module, much as
we do with doctest, simpleJSON, and we're about to do with unittest2.
It's a heavyweight option, but it would do the job. We could remove
the inclusion once we drop Python 2.4 support (possibly in Django
1.4).

A fifth option would be to catch the error cases and wrap them in a
backwards compatibility layer:

try:
logging.error('error message', extra={'foo': bar})
except TypeError:
    logging.error('error message')

The downside of this simple approach is that the handlers that need
status_code, request, and all the other useful details won't be able
to access them.

I haven't full investigated the options here, but we *might* be able
to do some fiddling with exc_info to work around this. If we mark a
logging call as exc_info=1, the stack frame is passed to the logging
handler; in cases where extra isn't available, we may be able to put
the variables we want into locals on the top stack frame, and check
for them when needed. It's a messy workaround, but it might just work
-- and then we can get rid of it as soon as we've dumped Python 2.4.

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-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: Problems with logging and Python 2.4

[Russell Keith-Magee]

2010/10/6 Łukasz Rekucki :
> Hi,
>
> I'm getting a whole bunch of errors related to logging on Python 2.4::
>
> ERROR: Missing templates are correctly reported by test client
> --
> Traceback (most recent call last):
>  File 
> "/home/lrekucki/projekty/django/django_trunk/tests/regressiontests/test_client_regress/models.py",
> line 583, in test_no_404_template
>    response = self.client.get("/no_such_view/")
>  File "/home/lrekucki/projekty/django/django_trunk/django/test/client.py",
> line 298, in get
>    response = self.request(**r)
>  File "/home/lrekucki/projekty/django/django_trunk/django/test/client.py",
> line 238, in request
>    response = self.handler(environ)
>  File "/home/lrekucki/projekty/django/django_trunk/django/test/client.py",
> line 79, in __call__
>    response = self.get_response(request)
>  File 
> "/home/lrekucki/projekty/django/django_trunk/django/core/handlers/base.py",
> line 139, in get_response
>    return self.handle_uncaught_exception(request, resolver, sys.exc_info())
>  File 
> "/home/lrekucki/projekty/django/django_trunk/django/core/handlers/base.py",
> line 182, in handle_uncaught_exception
>    extra={
>  File "/home/lrekucki/python/plain2.4//lib/python2.4/logging/__init__.py",
> line 999, in error
>    apply(self._log, (ERROR, msg, args), kwargs)
> TypeError: _log() got an unexpected keyword argument 'extra'
>
> Sadly, it's true - log functions don't have extra=* in Python 2.4[1].
> Possible solutions I can see right now:
>
>  * revert the logging patch (that would be quite bad)
>  * try to do some ugly monkey patching to the logging module
>  * drop Python 2.4 support
>
> Opinions ?

I shall now sing a selection of arias from the opera I have written,
entitled "Oh crap and buggery".

:-)

Dropping Python 2.4 would be the easiest solution, but as I've
commented previously, it really isn't an option. I really don't want
to revert logging -- the set of cases where it's useful vastly exceeds
the cases where it isn't.

Monkeypatching isn't a particularly attractive option.

A fourth option would be to include Python's logging module, much as
we do with doctest, simpleJSON, and we're about to do with unittest2.
It's a heavyweight option, but it would do the job. We could remove
the inclusion once we drop Python 2.4 support (possibly in Django
1.4).

A fifth option would be to catch the error cases and wrap them in
backwards compatibility:

try:

except TypeError:
logging.errro('error message')

-- 
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: AutoFields, legacy databases and non-standard sequence names.

[Tom Eastman]

On 06/10/10 16:02, Russell Keith-Magee wrote:

Yes - questions of usage and requests for design guidance should be
directed to Django-users.

Unless you have a specific suggestion for how to move ticket #1946
forward, this isn't a topic for django-developers.


Sorry, I should have been more clear.

What I'm trying to do is solicit suggestions from django developers as 
to how I *can* move ticket #1946 forward. I can find a way to work 
around it in my own project, but it would be ideal to solve it on the 
Django side, for everybody.


I mentioned there were three possible suggestions in the ticket 
discussion as to how to solve the problem.  If a Django developer can 
give me some guidance as to what approach seems to be the best long-term 
solution, I'm happy to try my hand at writing a patch that can hopefully 
be incorporated into the codebase.


Cheers,

Tom

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

AutoFields, legacy databases and non-standard sequence names.

[Tom Eastman]

Hey guys,

I'm using Django to create an interface for a legacy PostgresQL 
database.  The primary keys for my tables use sequences that aren't 
named the way django expects them to be (i.e. '__seq'), 
this means I can't call them AutoFields.


Essentially, my problem is identical to that described by


http://stackoverflow.com/questions/2516176/django-postgres-how-to-specify-sequence-for-a-field


and


http://code.djangoproject.com/ticket/1946


There appear to be three or so half-finished proposed solutions to this 
issue.  I definitely need to find a way to make this work, and I would 
greatly appreciate any guidance on what might be the best way to solve 
this problem.  If we can find a way to solve it for *everyone* that 
would be even better.


Any thoughts or suggestions?

Cheers,

Tom

--
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: #6735 -- Class based generic views: call for comment

[Ben Firshman]

Thanks to everyone who's helping push this forward. I would get stuck in, but 
I'm bogged down with work at the moment.

A couple of things from the wiki page that need doing:

1) Test coverage probably isn't great. Everything seems to work when I've used 
it in applications, but there's probably some stuff in there that isn't 
thoroughly tested.

2) Support for ModelForms isn't quite the same as our current generic views. 
For edit views, you can specify a model and the form is optional.

Ben

On 5 Oct 2010, at 15:43, Jacob Kaplan-Moss wrote:

> On Tue, Oct 5, 2010 at 8:03 AM, Russell Keith-Magee
>  wrote:
>> Ok - so to kick the process into the next phase, I've just created a
>> Django branch in my bitbucket repo [1] to cover introducing this to
>> trunk.
> 
> I gave this a quick review and nothing huge jumped out. Looks good so far.
> 
> One point of concern that came up though: looking at the way as_view
> introduces a closure, it occurs to me that the docstring of am
> as_view'd class view isn't very useful, which'll break introspection
> and things like the admindocs tool. And just using functools.wraps (or
> the equivalent) is as_view won't exactly work, either: you'll get the
> dispatch() docstring instead.
> 
> So unless anyone can think of a reason why it'd be a bad idea, I think
> as_view needs to monkeypatch the class's docstring into the returned
> closure. Bit of a code smell, but I think it maintains the correct
> self-documenting nature of a view, yeah?
> 
>>  * Does RequestFactory need to be added to Django's test tools
>> (Possibly fixing #9002)?
> 
> I'm not sure it's directly class-based-views-related, but I believe it
> should, yes. It's a useful pattern that makes it into a utils module
> in nearly every app I write.
> 
>>  * Does django.views.generic.utils.coerce_put_post() indicate a change
>> that needs to be made in Django? (Is there an existing ticket for
>> this?)
> 
> Yeah, this has been a wart in Django for a while -- Django doesn't
> really "get" PUT very well. Along the same lines,
> request.raw_post_data is terribly named. I don't know that there's a
> single ticket anywhere, but I'd like to see a general cleanup here.
> 
> I don't see this as a blocker for class-based views, though: we have a
> narrow feature deadline that I'd like to hit, and then a longer
> bug-fix period we can use to clean up PUT/POST and such.
> 
>>  * Are there any outstanding tickets on generic views that will be
>> closed by merging this branch, and do they ask for any features that
>> aren't fixed by this branch?
> 
> Almost certainly yes :)
> 
> We could *really* use a volunteer who can wade through the open
> tickets, look at all the GV-related tickets, and answer this question
> concretely.
> 
> Anyone? Bueller?
> 
> Jacob
> 
> -- 
> 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.
> 

-- 
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: #6735 -- Class based generic views: call for comment

[Luke Plant]

On Tue, 2010-10-05 at 22:29 +0100, I wrote:

> Russell - beware - I think bitbucket has managed to create a very broken
> clone. I did a fork as well, and both of our repositories are missing
> thousands of commits.  I can do a pull from django/django and I then get
> a complete repository which then seems to be compatible with
> django/django.  I've e-mailed the bitbucket folks, but have left my
> clone as it is for now to allow them to work out what has gone wrong.

It seems that the clones being created are not corrupted, but bitbucket
is choosing a 'forkpoint' which means that you get a partial repository.
You can get a full repository by pulling from django/django and pushing
back to your clone.  It would be helpful if you did that on your clone
Russell - at the moment if I do 'hg outgoing freakboy' I get thousands
of commits that you are missing.

Thanks,

Luke

-- 
"Dysfunction: The only consistent feature of all of your 
dissatisfying relationships is you." (despair.com)

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

Problems with logging and Python 2.4

[Łukasz Rekucki]

Hi,

I'm getting a whole bunch of errors related to logging on Python 2.4::

ERROR: Missing templates are correctly reported by test client
--
Traceback (most recent call last):
  File 
"/home/lrekucki/projekty/django/django_trunk/tests/regressiontests/test_client_regress/models.py",
line 583, in test_no_404_template
response = self.client.get("/no_such_view/")
  File "/home/lrekucki/projekty/django/django_trunk/django/test/client.py",
line 298, in get
response = self.request(**r)
  File "/home/lrekucki/projekty/django/django_trunk/django/test/client.py",
line 238, in request
response = self.handler(environ)
  File "/home/lrekucki/projekty/django/django_trunk/django/test/client.py",
line 79, in __call__
response = self.get_response(request)
  File 
"/home/lrekucki/projekty/django/django_trunk/django/core/handlers/base.py",
line 139, in get_response
return self.handle_uncaught_exception(request, resolver, sys.exc_info())
  File 
"/home/lrekucki/projekty/django/django_trunk/django/core/handlers/base.py",
line 182, in handle_uncaught_exception
extra={
  File "/home/lrekucki/python/plain2.4//lib/python2.4/logging/__init__.py",
line 999, in error
apply(self._log, (ERROR, msg, args), kwargs)
TypeError: _log() got an unexpected keyword argument 'extra'

Sadly, it's true - log functions don't have extra=* in Python 2.4[1].
Possible solutions I can see right now:

 * revert the logging patch (that would be quite bad)
 * try to do some ugly monkey patching to the logging module
 * drop Python 2.4 support

Opinions ?

[1]: http://docs.python.org/library/logging.html#logging.debug

-- 
Łukasz Rekucki

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

Contributing "How To"

[Gabriel Hurley]

There has been repeated talk of putting together resources for new
contributors in a way that's more accessible and to-the-point than the
current contributing docs. Most recently Russell mentioned it in this
thread:

http://groups.google.com/group/django-developers/browse_frm/thread/9ebc3e57d539d1ff

I would like to put such a page in the official docs together, and to
that end I have created a wiki page to serve as the basis for the
eventual patch:

http://code.djangoproject.com/wiki/ContributingHowTo

I've also opened a ticket to hold the eventual patch and track the
issue:

http://code.djangoproject.com/ticket/14401

Contributions to the wiki page are more than welcome!

Thanks,

- Gabriel

-- 
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: Site app should be able to make absolute URLs #10944

[Gabriel Hurley]

I added some feedback on the ticket. Looks like a good start!

- Gabriel

On Oct 4, 2:12 pm, Laurent Luce  wrote:
> Hello,
>
> I added a patch to this ticket http://code.djangoproject.com/
> ticket/10944">#10944
>
> - add method get_url to Site model to return an absolute url based on
> a relative path passed as an argument.
> - add site_url template tag doing the same
>
> I am not sure about the method and template tag names. Better naming
> is welcome.
>
> Can someone review the patch?
>
> I will work on the documentation changes when I get more feedback.
>
> Laurent Luce

-- 
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: #6735 -- Class based generic views: call for comment

[Luke Plant]

On Tue, 2010-10-05 at 21:03 +0800, Russell Keith-Magee wrote:

> Ok - so to kick the process into the next phase, I've just created a
> Django branch in my bitbucket repo [1] to cover introducing this to
> trunk.

Russell - beware - I think bitbucket has managed to create a very broken
clone. I did a fork as well, and both of our repositories are missing
thousands of commits.  I can do a pull from django/django and I then get
a complete repository which then seems to be compatible with
django/django.  I've e-mailed the bitbucket folks, but have left my
clone as it is for now to allow them to work out what has gone wrong.

Luke

-- 
"Doubt: In the battle between you and the world, bet on the world." 
(despair.com)

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-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: #6735 -- Class based generic views: call for comment

[legutierr]

On Oct 5, 10:43 am, Jacob Kaplan-Moss  wrote:
> >  * Does django.views.generic.utils.coerce_put_post() indicate a change
> > that needs to be made in Django? (Is there an existing ticket for
> > this?)
>
> Yeah, this has been a wart in Django for a while -- Django doesn't
> really "get" PUT very well. Along the same lines,
> request.raw_post_data is terribly named. I don't know that there's a
> single ticket anywhere, but I'd like to see a general cleanup here.
>
> I don't see this as a blocker for class-based views, though: we have a
> narrow feature deadline that I'd like to hit, and then a longer
> bug-fix period we can use to clean up PUT/POST and such.

I just wanted to underline what most people here already know: that
according to the html 4 spec [1], the only acceptable values for
form's method attribute are GET and POST.  Also, in common practice,
PUT is used primarily in making ajax calls, or in accessing
programatic JSON or XML APIs, not in html forms.  HTML5 does specify
PUT as a possible value for that attribute, but if you are planning on
improving your support of PUT, I have to believe that it is
*primarily* because you want to improve the ability to implement
programatic APIs in Django.

However, as I have detailed in my last two posts in this thread, the
current implementation, lacks any ajax/json/xml support.  In those two
posts I have detailed possible modifications to the code that would
allow ajax support to be introduced.  I think that Andrew Godwin's
remarks contribute quite a bit to that discussion, but no one else
responded yet.  This is something that needs to be tangibly addressed.

I am worried that with the pace that things are going here that ajax
support may be ignored, or just pasted-on at the last minute.
Clearly, you see this as an important feature, or you wouldn't be
considering improving PUT support, and wouldn't be supporting the
DELETE verb.  If ajax/json/xml are to be supported by the generic view
classes, however, some refactoring has to be made to the code.

[1] http://www.w3.org/TR/REC-html40/interact/forms.html#h-17.3

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

update man django-admin.1 to include missing commands

[Laurent Luce]

Hello,

I added a patch to this ticket: http://code.djangoproject.com/ticket/14391

This is to make django-admin.1 in sync with django-admin.py

Laurent Luce

-- 
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: #6735 -- Class based generic views: call for comment

[Łukasz Rekucki]

On 5 October 2010 22:10, David Larlet  wrote:
>
>
> Jacob Kaplan-Moss a écrit :
>>
>> On Tue, Oct 5, 2010 at 8:03 AM, Russell Keith-Magee
>>   wrote:
>>>
>>>  * Are there any outstanding tickets on generic views that will be
>>> closed by merging this branch, and do they ask for any features that
>>> aren't fixed by this branch?
>>
>> Almost certainly yes :)
>>
>> We could *really* use a volunteer who can wade through the open
>> tickets, look at all the GV-related tickets, and answer this question
>> concretely.
>>
>> Anyone? Bueller?
>
> #1282: archive_today generic view should accept a month_format parameter
> instead of hardcoding '%b'
> Done, through MonthView.month_format
>
> #2367: pagination for date based generic views
> Depends on http://github.com/bfirsh/django-class-based-views/pull/2
>
> #8378: Generic views cache-like behavior
> Last edited one year ago, not sure if it's still relevant
>
> #13753: Generic views don't redirect to an URL name, like
> django.shortcuts.redirect does
> Done, no more post_save_redirect argument but View.redirect_to()
>
> #13842: XViewMiddleware fails with class-based views
> Must be fixed before class-based views merge.
>
> I hope I didn't forget one, it's really hard to search with Trac...
>

(few more found in this query[1])

#9150: Generic views should accept arguements for form_class (related to #12392)

Mostly fixed by adding "initial" parameter in FormMixin. This could be
changes to get_initial(), so it can be based on request object.

#12669: Return different HttpResponse from direct_to_template

Use a TemplateView with get_response() overriden. The patch on the
ticket adds a response class as a parameter. Should we add a similar
to TemplateView ?

#13953: Generic CRUD views: support for callable in post_ACTION_redirect

There are no post_ACTION_redirect parameters anymore, can be done by
overriding redirect_to()

[1]: 
http://code.djangoproject.com/query?status=new=assigned=reopened=Generic+views=priority

-- 
Łukasz Rekucki

-- 
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: #6735 -- Class based generic views: call for comment

[David Larlet]

Jacob Kaplan-Moss a écrit :

On Tue, Oct 5, 2010 at 8:03 AM, Russell Keith-Magee
  wrote:

  * Are there any outstanding tickets on generic views that will be
closed by merging this branch, and do they ask for any features that
aren't fixed by this branch?


Almost certainly yes :)

We could *really* use a volunteer who can wade through the open
tickets, look at all the GV-related tickets, and answer this question
concretely.

Anyone? Bueller?


#1282: archive_today generic view should accept a month_format parameter 
instead of hardcoding '%b'

Done, through MonthView.month_format

#2367: pagination for date based generic views
Depends on http://github.com/bfirsh/django-class-based-views/pull/2

#8378: Generic views cache-like behavior
Last edited one year ago, not sure if it's still relevant

#13753: Generic views don't redirect to an URL name, like 
django.shortcuts.redirect does

Done, no more post_save_redirect argument but View.redirect_to()

#13842: XViewMiddleware fails with class-based views
Must be fixed before class-based views merge.

I hope I didn't forget one, it's really hard to search with Trac...

Best,
David

--
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: #6735 -- Class based generic views: call for comment

[legutierr]

On Oct 4, 1:04 pm, Andrew Godwin  wrote:
> On 04/10/10 17:28, legutierr wrote:
>
> >    * First, treat data processing and retrieval as separable from
> > rendering.  Create a bright line of separation between the two
> > conceptual elements of the view (data and rendering), and do it early
> > on, at a high level, inside dispatch().  Instead of expecting the
> > ListView.GET to return an HTTPResponse, for example, have it return a
> > context or a context dictionary that could be reused with several
> > render_result() implementations.
>
> This is problematic if I want to return something that isn't a context,
> or like it (for example, if I'm rendering images, or fetching content
> wholesale out of a database).

What I am suggesting is not that overriding render_result would be
sufficient for 100% of cases, but that it would be sufficient for 99%
of cases where a standard data dictionary could be used to generate
the response, whatever it may be.  And while it is *conceivable* that
one would want to use ListView, DetailView, etc. functionality in
combination with image rendering, or other kind of unexpected content,
it is not likely.

However, it *is* likely that one would want to use ListView,
DetailView, etc. to produce JSON, XML, PDF or other text-like content,
which is the common user expectation that *needs* to be addressed.
Overriding dispatch() to implement less standard functionality, or
overriding get() at the same time as render_result(), would still be
feasible for other cases where a simple data dictionary is
insufficient for rendering.  But if it is just a question of how text
is being output, then custom implementation of
render_result(data_dictionary) would be sufficient in 99% of cases.

> So, bfirsh's previous iteration had content formats built into the base
> class - I ripped it out and replaced it with a simpler base class, and
> he seemed to agree, so that's where we currently are.

Your simpler base class seems like a big improvement.  What I'm
addressing is the fact that instead of subclassing directly from the
simple base class (which makes no assertion about what type of data is
being returned, a very good thing), ListView, DetailView et al.
subclass TemplateView.  I would assert that the actual rendering logic
should be implemented as a mixin, and combined with ListView,
DetailView, etc. in order to produce the user-oriented generic view
classes.  That way, alternative rendering implementations would be
much more trivial to add, and without creating a misleading class
hierarchy (i.e., by having the JSONView also be a TemplateView).

> My main concern is getting rid of the simplicity - e.g. of calling
> render() on a template/context mix. In this aforementioned previous
> iteration, if I wanted to supply custom context to a custom template, I
> had to override both self.get_template_name() and self.get_context() -
> even though it would have been a lot easier to override GET and just
> call self.render(). It's a similar problem to passing everything around
> as keyword arguments - reusability doesn't turn out to be much better
> than starting from scratch.

In the particular approach that I am describing, you could still
override GET to modify what data is to be put into the context.  And
since the TemplateView render_template() implementation would use
self.request to build a RequestContext, you would still be able to use
context processors.  The difference is that if you wanted to modify
*both* what data is being added to the context and do custom stuff
with the output data, you would have to override both GET() and
render_result()/render_template().  Or you could just override
dispatch()/as_view() in any case.

> I just don't want us to build in all these abstraction layers and have
> the ability to customise everything perfectly but in a verbose fashion.
> That said, if render_result() in your example just calls a normal
> render() method itself, it's easy to not use it if you don't have to, so
> a reasonable approach to get both of these angles in is possible.

render_result(data_dictionary) would call render_template(template,
context) in the case of the TemplateViewMixin, just as
render_to_response() does in the current implementation.  However, in
the case of a JSONViewMixin, render_result() would process the data
dictionary to produce json output instead.  I actually think that this
makes things much less verbose overall.

The trickier question is whether one might want to implement a
MultiViewMixin, capable of outputing *both* html documents and json,
for example by registering MyView.as_view and MyView.as_ajax_view in
urls.py.  If you look through the use cases I list below, in each of
these use cases a user would benefit from being able to register two
different views with two different urls using the same view class
implementation.  The current implementation makes this impossible
without overriding mostly everything.

> Also, what use cases do 

Re: #6735 -- Class based generic views: call for comment

[Luke Plant]

On Tue, 2010-10-05 at 09:43 -0500, Jacob Kaplan-Moss wrote:

> One point of concern that came up though: looking at the way as_view
> introduces a closure, it occurs to me that the docstring of am
> as_view'd class view isn't very useful, which'll break introspection
> and things like the admindocs tool. And just using functools.wraps (or
> the equivalent) is as_view won't exactly work, either: you'll get the
> dispatch() docstring instead.
> 
> So unless anyone can think of a reason why it'd be a bad idea, I think
> as_view needs to monkeypatch the class's docstring into the returned
> closure. Bit of a code smell, but I think it maintains the correct
> self-documenting nature of a view, yeah?

Sounds fine to me, and I think it should also copy other function
attributes from the dispatch method, to allow people to apply decorators
like 'csrf_exempt' to the dispatch method and have it work as expected.

We might like to think about whether we add any other mechanism for
decorators.  We already have the ability to decorate the result of
'as_view()', which is best suited for things like 'cache_page', and to
decorate methods like dispatch, which is best suited for decorators that
are required for the view to work correctly.  A list of decorators could
also be specified as a class/instance attribute and added inside the
'as_view' to the closure that is returned.  For the moment, I think
adding this would add too many choices, and if there is a need for it we
can add it as a feature later.

Luke

-- 
"Doubt: In the battle between you and the world, bet on the world." 
(despair.com)

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-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: #6735 -- Class based generic views: call for comment

[Andy McKay]

On 2010-10-01, at 3:57 PM, David P. Novakovic wrote:
> I may be missing something obvious here, so please tell me if I am..
> but couldn't the resolver just check that quacks like something
> OOViewish has been passed in and simply branch and init the class
> before calling the view in the same way it normally would?

That's what I've done on quite a few projects and its worked great. As Russell 
pointed out I lose decoratoring in urls.py, but that's something I don't use 
anyway.
--
  Andy McKay
  a...@clearwind.ca
  twitter: @andymckay
 

-- 
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: #6735 -- Class based generic views: call for comment

[Jacob Kaplan-Moss]

On Tue, Oct 5, 2010 at 8:03 AM, Russell Keith-Magee
 wrote:
> Ok - so to kick the process into the next phase, I've just created a
> Django branch in my bitbucket repo [1] to cover introducing this to
> trunk.

I gave this a quick review and nothing huge jumped out. Looks good so far.

One point of concern that came up though: looking at the way as_view
introduces a closure, it occurs to me that the docstring of am
as_view'd class view isn't very useful, which'll break introspection
and things like the admindocs tool. And just using functools.wraps (or
the equivalent) is as_view won't exactly work, either: you'll get the
dispatch() docstring instead.

So unless anyone can think of a reason why it'd be a bad idea, I think
as_view needs to monkeypatch the class's docstring into the returned
closure. Bit of a code smell, but I think it maintains the correct
self-documenting nature of a view, yeah?

>  * Does RequestFactory need to be added to Django's test tools
> (Possibly fixing #9002)?

I'm not sure it's directly class-based-views-related, but I believe it
should, yes. It's a useful pattern that makes it into a utils module
in nearly every app I write.

>  * Does django.views.generic.utils.coerce_put_post() indicate a change
> that needs to be made in Django? (Is there an existing ticket for
> this?)

Yeah, this has been a wart in Django for a while -- Django doesn't
really "get" PUT very well. Along the same lines,
request.raw_post_data is terribly named. I don't know that there's a
single ticket anywhere, but I'd like to see a general cleanup here.

I don't see this as a blocker for class-based views, though: we have a
narrow feature deadline that I'd like to hit, and then a longer
bug-fix period we can use to clean up PUT/POST and such.

>  * Are there any outstanding tickets on generic views that will be
> closed by merging this branch, and do they ask for any features that
> aren't fixed by this branch?

Almost certainly yes :)

We could *really* use a volunteer who can wade through the open
tickets, look at all the GV-related tickets, and answer this question
concretely.

Anyone? Bueller?

Jacob

-- 
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: #6735 -- Class based generic views: call for comment

[Russell Keith-Magee]

On Tue, Oct 5, 2010 at 12:59 PM, Russell Keith-Magee
 wrote:
> On Tue, Oct 5, 2010 at 3:16 AM, Luke Plant  wrote:
>> On Mon, 2010-10-04 at 13:08 -0400, Alex Gaynor wrote:
>>
>>> Last idea, I swear,
>>
>> I didn't swear, so here is another slight variation :-) You actually
>> *call* the classmethod in your URLconf, passing any constructor
>> arguments to it:
>>
>> url(r'^detail/author/(?P\d+)/$',
>>        views.AuthorDetail.as_view(some_param=123),
>>        name="author_detail"),
>>
>> It returns a newly created view function, which in turn calls your
>> class.
>>
>> http://bitbucket.org/spookylukey/django-class-views-experiments/src/tip/classmethod2.py
>
> This looks to me like it could be a winner. The fact that
> AuthorDetail(foo=bar).as_view(pork=spam) ignores the 'foo' argument is
> a minor wart, but a lot less concerning to me that the potential
> threading problems in copy+call, or the 'no state on self' options.
>
> Thanks for working up the examples, Luke!

Ok - so to kick the process into the next phase, I've just created a
Django branch in my bitbucket repo [1] to cover introducing this to
trunk.

I've used the implementation in Ben's github repo [2] as a starting
point -- it looks like David Larlet has already made the changes to
implement the classmethod2 approach.

So far, other than some reorganization to get everything into Django's
tree, I've made two changes:

 * Added PendingDeprecationWarnings to the old function-based generic views

 * Following a late night IRC conversation, I've done some PEP8
bikeshedding, and renamed the request methods GET(), POST() etc to
lower case get(), post().

Some other issues that still need to be resolved:

 * Does RequestFactory need to be added to Django's test tools
(Possibly fixing #9002)?

 * Does django.views.generic.utils.coerce_put_post() indicate a change
that needs to be made in Django? (Is there an existing ticket for
this?)

 * Are there any outstanding tickets on generic views that will be
closed by merging this branch, and do they ask for any features that
aren't fixed by this branch?

 * We need to reference and topic docs to describe the new view classes.

 * We need to update the tutorial to use the new view classes

Pull requests gratefully accepted for any of these items :-)

[1] http://bitbucket.org/freakboy3742/django
[2] http://github.com/bfirsh/django-class-based-views

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