Re: Improving Class based views names

[Carl Meyer]

On 03/21/2011 09:14 AM, daonb wrote:
> On Mar 20, 4:49 am, Carl Meyer  wrote:
>> Those last five characters in "get_context_data" actually serve quite a
>> useful purpose, IMO. They clarify that the return value is just the data
>> that will go into building a context (a dictionary), as opposed to being
>> the Context or RequestContext object itself, which is what I'd expect
>> from a method named "get_context".
> 
> Good point. I might be splitting hairs, but _data isn't clear enough -
> both a dict and a Context objects satisfy `data`. Looking at
> RequestContext code, I found __init__ gets a `dict` parameter, so how
> about making it get_context_dict?

Sure - except that these decisions were made several months ago, and
these kinds of considerations needed to have been raised then. We've had
a beta and an RC release with these names, and will have 1.3 any time
now; there's simply zero chance that we'll break things for everyone
who's already started working with CBVs in order to make tiny
improvements to method names.

Carl

-- 
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: Improving Class based views names

[daonb]

On Mar 20, 4:49 am, Carl Meyer  wrote:
>
> Those last five characters in "get_context_data" actually serve quite a
> useful purpose, IMO. They clarify that the return value is just the data
> that will go into building a context (a dictionary), as opposed to being
> the Context or RequestContext object itself, which is what I'd expect
> from a method named "get_context".
>

Good point. I might be splitting hairs, but _data isn't clear enough -
both a dict and a Context objects satisfy `data`. Looking at
RequestContext code, I found __init__ gets a `dict` parameter, so how
about making it get_context_dict?

Benny

-- 
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: Improving Class based views names

[daonb]

> The names used by the generic views are (as far as I am aware)
> internally consistent within the views, and with the old generic
> views. The choice to use pk instead of object_id was quite deliberate,
> because every object responds to pk, but not necessarily to id.
>

I don't believe it's backward compatible with the current generic
views - 
http://docs.djangoproject.com/en/1.2/ref/generic-views/#django-views-generic-list-detail-object-detail.
IMHO, it's the other way around: every viewable object got to have
some kind of an id, but not necessarily a pk. In the case an object
comes from the db the object_id is the primary key, in case I choose
to override the get_object method I can use the object_id to retrieve
an object from a dataset that has no  primary keys.


> Compatibility with third party libraries isn't really a consideration
> unless the general community has converged on a convention which a new
> Django feature has blindly ignored. In this case, I would argue that
> pk is the convention, and Django-backlinks is in need of an update.

hmm, I was under the impression `object_id` is the convention for urls
and views while pk is used for models. Maybe, I'm wrong, but searching
the docs, I found it was referenced by admin, contenttypes, comments
and of course generic views.

Benny

-- 
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: Improving Class based views names

[Carl Meyer]

Hi Benny,

On 03/19/2011 05:41 PM, daonb wrote:
> Migration to the beta was quite smooth except for two names that broke
> my code: `pk` & `get_context_data`. The first comes from `models` and
> is now used instead of `object_id` in urls and views. It also broke
> compatibility with django-backlinks and I was forced to support both
> `pk` and `object_id` in the view wrapper, ugly. The second name can be
> rinsed and lose it's last 5 chars.

Those last five characters in "get_context_data" actually serve quite a
useful purpose, IMO. They clarify that the return value is just the data
that will go into building a context (a dictionary), as opposed to being
the Context or RequestContext object itself, which is what I'd expect
from a method named "get_context".

Carl

-- 
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: Improving Class based views names

[Russell Keith-Magee]

On Sunday, March 20, 2011, daonb  wrote:
> Hi,
>
> I'm in the middle of re-factoring a pretty active open parliament
> project into 1.3. I've been an early adaptor of class based views,
> using it of Jacob's fork.
>
> Migration to the beta was quite smooth except for two names that broke
> my code: `pk` & `get_context_data`. The first comes from `models` and
> is now used instead of `object_id` in urls and views. It also broke
> compatibility with django-backlinks and I was forced to support both
> `pk` and `object_id` in the view wrapper, ugly. The second name can be
> rinsed and lose it's last 5 chars.

Hi Benny,

Thanks for the feedback. However, I'm a little confused as to what you
are proposing.

The names used by the generic views are (as far as I am aware)
internally consistent within the views, and with the old generic
views. The choice to use pk instead of object_id was quite deliberate,
because every object responds to pk, but not necessarily to id.

Compatibility with third party libraries isn't really a consideration
unless the general community has converged on a convention which a new
Django feature has blindly ignored. In this case, I would argue that
pk is the convention, and Django-backlinks is in need of an update.

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.

Improving Class based views names

[daonb]

Hi,

I'm in the middle of re-factoring a pretty active open parliament
project into 1.3. I've been an early adaptor of class based views,
using it of Jacob's fork.

Migration to the beta was quite smooth except for two names that broke
my code: `pk` & `get_context_data`. The first comes from `models` and
is now used instead of `object_id` in urls and views. It also broke
compatibility with django-backlinks and I was forced to support both
`pk` and `object_id` in the view wrapper, ugly. The second name can be
rinsed and lose it's last 5 chars.

Thanks,

Benny

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