Still sounds like an issue with the docs to me, and while they do still
have some issues, I'm a big supporter of the CBVs.
I've posted this here before, but http://ccbv.co.uk/ really helps cut out
most of the pain of the "looking through the source code" stage of
understanding the CBVs because
On 1 June 2012 16:54, Jacob Kaplan-Moss wrote:
> I think this might be a situation where we need some more feedback
> from the community and some more time to decide what the right move
> here is.
>
> So... what do *you* think?
I've used CBV's in one app so far, and have wound up only using View
Glad to see this debate happening, because for a long time I felt like I
was the only one who had issues with CBVs. I forced myself to use CBVs
(custom and generics) on two major projects and I'm still struggling to see
the real value in them.
Luke's post did an excellent job of articulating th
On Fri, Apr 20, 2012 at 9:01 AM, Anssi Kääriäinen
wrote:
> On Apr 12, 10:27 pm, Anssi Kääriäinen wrote:
>> > So perhaps we do need the signal inheritance behavior to be opt-in when
>> > connecting the signal handler. I think I'd like to see a deprecation
>> > path so that eventually the inheritan
Glad to see this debate happening, because for a long time I felt like I
was the only one who had issues with CBVs. I forced myself to use CBVs
(custom and generics) on two major projects and I'm still struggling to see
the real value in them.
Luke's post did an excellent job of articulating th
Hi all,
Following the BDFL pronouncement of a preferred option for
customisable User models in contrib.auth [1], I've just pushed a
branch to Github that contains a draft implementation [2].
It's not ready for trunk quite yet, but you can use this code to set
up a custom User model, and then log
Hi all,
Recently, I have been working on some patches for
contrib.sessions. These include server side sessions expiry check
(#18194) and some other trivial changes. These changes are in the pull
request [#78][pull-78]
The expiry checks is be done in the base backend, i.e. inherited by
every backe
We (Votizen) hosted a 1-day sprint yesterday from 10a to 6p. I had
capped attendance at 30 just for logistical reasons - there's room for
more but I wanted to gauge interest.
24 people signed up, and I'd guess that about 20 people total were
there for at least part of the day. I think we peaked
On 01/06/12 15:54, Jacob Kaplan-Moss wrote:
> On Fri, Jun 1, 2012 at 10:14 AM, Victor Hooi wrote:
>> The reason for my post - is there anything from the Django core as a whole
>> on this? What's the future roadmap like in terms of CBV's? Are there going
>> to be any changes to it, or are we safe t
On Jun 4, 6:12 pm, Russell Keith-Magee
wrote:
> * The swapping mechanic is set up using a new Meta option on models
> called 'swappable' that defines the setting where an alternate model
> can be defined. Technically, the swappable option *could* be used for
> any model; however, I'm not proposin
Hi,
Sorry for being late with weekly update. Due to some issues with Meta
and my wrong understanding of metaclasses that Russell pointed I spend
time on enhance my knowledge about this. I rewrote also some part of
code that I have written week before.
This week I will do what I was suppose to
On Jun 4, 5:58 pm, Jeremy Dunck wrote:
> On Fri, Apr 20, 2012 at 9:01 AM, Anssi Kääriäinen
> > Could we force the caller to define the wanted signal inheritance mode
> > when .connect() is called? The inherit mode must be one of True,False
> > or None. Default of None means no inheritance (as now)
There is a plan to do some work on the docs at the djangocon sprints - in
particular trying to get some examples of when you 'could' and when you
'should not' use the generic CBVs.
With regards to Zach's point about TDD testing - some of that may simply be
familiarity. I don't know about you bu
13 matches
Mail list logo
