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
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 ob
> 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 back
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-backlink
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:
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 `model
