Re: Class based generic views in 1.3?

more readable and it will help users' make their views cleaner. My fork is at http://github.com/daonb/django-class-based-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 dj

Re: Class based generic views in 1.3?

On Jun 16, 4:45 pm, Ben Firshman wrote: > > The request is passed round so methods look like views to decorators. > Magically dropping it for decorators seems a bit scary. :/ > The way I see it a good framework need to establish a clear contract with its user. In our case, Django publishes a con

Improving Class based views names

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

Re: Improving Class based views names

> 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

Re: Improving Class based views names

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

Re: class based views: object instead of dictionary as context?

Hi Reinout, IMHO, Django's philosophy is that template designers are highly skilled designers and not coders. To make it possible for designers to edit the templates themselves, Django requires the developer to create a simple context dictionary for designers to understand. In all of my projects

Is it time for a django-evangelists group?

Hi all, I've organized the testing sprint in Israel this Sunday and it was a great experience. The idea was to beta test 1.0 - getting new users through the tutorial and some 0.96 users to port their apps to 1.0. Overall we didn't find any serious bugs although porting is going to be painful... Ma

Re: Help needed: Django 1.0 release notes and porting guide

I'll take the porting guide - ticket #8438. Although I'm not going to be in Portland, I'll do my best to have a draft ready by the weekend. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. T

Re: A (last-minute) compromise on {% url %}

+1 for a sweet feature. --~--~-~--~~~---~--~~ 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

Re: New milestones for ticket triagers

I'm with the grasshoper. We've been patient for quite a while, but we need a release framework so us mortals (==non-core developers) can safely post ticketsm. We've been quite, not wanting to interfere with the crucial work of releasing 1.0, but we have alot of good ideas that need documentation J

Re: New milestones for ticket triagers

> Er, Django 1.0 was only released _3 days_ ago.  You know people are > literally sitting down to the start of Djangocon right now, right? Sorry, but I don't. I know it's been a tremendous effort and a great achievement to get 1.0 out on time and I'm thankful for all those who contributed. I'm no

Re: ANNOUNCE: Django 1.0 released

Mazal Tov to all the perfectionists for a great version of a great framework. We're having a street party tonight in TLV celebrating the release of 1.0. We'll have a lot of beer and Humus. Here's the link (in Hebrew) http://tinyurl.com/645tmv. Lechaim! Benny -- http://frien

Re: implementing app specific default settings

IMHO installing a new app should require user intervention. I don't want to see new apps magically popping out and I don't want to dynamically load anyone else's settings.py. I love the code I get from pluggable apps but I prefer to keep settings.py for myself... Why not have a manage.py *installa

Feeds refactoring

Hi all, I'm a part of the Django user group in Israel and we want to have our own project, taking a part of the Django project and improving it. I've discussed it with Jacob, Adrian and Alex yesterday and they all agreed that the feeds module needs refactoring. So, if you're working on it now or i

Re: Feeds refactoring

>  * Builtin support for the full Atom publishing protocol. This is > already logged as ticket (#3569) and was originally accepted for v1.1, > but got delayed in the interest of the schedule. Makes sense to support RFC 4287. I think it will help if we drop RSS support and support only Atom. I'm +