Hi all,
Haven't seen a comment on this topic for a few days, so was wondering
if a core dev can make a design decision yet. I have some spare time
in the remainder of this week, so if the (universal) decorator-
approach is chosen, I should be able to finish it shortly (the mixin-
approach i
On Sep 20, 2011, at 5:50 PM, Tom Evans wrote:
On Tue, Sep 20, 2011 at 4:12 PM, Roald de Vries
wrote:
I don't see how this is different from the create method on the
intermediary
model.
Cheers, Roald
PS: I found an open ticket on this,
https://code.djangoproject.com/ticket/9475
On Sep 20, 2011, at 4:23 PM, Stephan Jaensch wrote:
Am 20.09.2011 um 15:52 schrieb Roald de Vries:
Is there a fundamental reason that I'm missing (other than
"nobody's taken the trouble of writing it") that I can't do the
following? If there isn't I'll cr
Hi all,
Is there a fundamental reason that I'm missing (other than "nobody's
taken the trouble of writing it") that I can't do the following? If
there isn't I'll create a ticket for it.
class R(Model):
user = ForeignKey(User)
my_model = ForeignKey('MyModel')
comm
On Sep 16, 2011, at 6:19 PM, Donald Stufft wrote:
Documentation is being worked on, and is orthogonal to the current
discussion of how
to handle things like requiring logins with the new CBVs.
I just watched "Class Decorators: Radically Simple" by Jack Diederich,
who wrote the class decora
On Sep 16, 2011, at 11:42 AM, Łukasz Rekucki wrote:
On 16 September 2011 10:17, Roald de Vries wrote:
On Sep 16, 2011, at 12:11 AM, Łukasz Rekucki wrote:
I would like to also comment on the new approach in that ticket.
Making a shallow copy of a class is *MAGIC* to me. It breaks the
basic
On Sep 16, 2011, at 10:08 AM, Jonathan Slenders wrote:
class ProtectedView(MyView):
login_required = True
Where 'MyView' checks all the view's options during a dispatch. Never
liked inheritance with multiple base classes...
How would I create my own 'decorators' in this approach?
Cheers,
Hi,
On Sep 16, 2011, at 12:11 AM, Łukasz Rekucki wrote:
Hi,
On 15 September 2011 22:44, Jacob Kaplan-Moss
wrote:
#14512 proposes a adding another view-decorator-factory for
decorating
class-based views, which would turn the above into::
@class_view_decorator(login_required)
clas
On Sep 13, 2011, at 9:28 PM, Reinout van Rees wrote:
On 13-09-11 20:33, Tobias McNulty wrote:
I love it when problems solve themselves :-)
That's a good point. Are there *any* methods in the CBVs that don't
take arguments, that also modify data? The only one that I found
in the
list
Hi Gregor,
On the way home from DjangoCon I realized there is a (IMHO) elegant
solution to this problem that is closer to the nature of django's
template language.
What you want with form-rendering is having defaults, but being able
to override them; which is something you can do with dja
Dear all,
I have a model with a foreign key with null=True:
class Many(Model):
ForeignKey(One, null=True)
class One(Model):
pass
Now if I do:
one = One()
... then:
one.many_set.all()
... returns all Many's with 'self.one_id == None'.
From an implementation
On Oct 28, 2010, at 4:02 PM, Javier Guerra Giraldez wrote:
On Thu, Oct 28, 2010 at 2:54 AM, Roald de Vries
wrote:
I quite often reference foreign keys of foreign keys of foreign
keys...
Wouldn't it be nice to have a 'through'-parameter for ForeignKey's?
clas
Dear all,
I quite often reference foreign keys of foreign keys of foreign
keys... Wouldn't it be nice to have a 'through'-parameter for
ForeignKey's?
class A(Model):
b = ForeignKey('B')
c = ForeignKey('C', through='B', related_name='a_set')
class B(Model):
Hi Ben,
I like your implementation, but I don't really like the class name
'View'; I would opt for 'Resource' (or 'ResourceHandle').
Why I don't like 'View':
- It's a very abstract thing, it's conceptually defined as 'the thing
that maps a request to a response', or something alike
- Insta
14 matches
Mail list logo
