rns of the form ('...', my_view)
can be user, where my_view is just a class derived from View. I also
think that the solution to redirection (lines 32-39) is pretty
elegant.
I'm looking forward to your comments.
Cheers, Roald
--
You received this message because you are subscribed to the Goo
On 2 jun, 23:22, Luke Plant wrote:
> On Wednesday 02 June 2010 16:08:24 Roald wrote:
> > class View(HttpRequest):
> > def __init__(self, request, *args, **kwargs):
> > ...
> > super(View, self).__init__(self.content())
&
On 3 jun, 19:33, Luke Plant wrote:
> On Thursday 03 June 2010 08:59:31 Roald wrote:
> > > One reason against this is it makes it harder to re-use other
> > > views from within the View.
> > I don't really understand what you mean. Do you mean re-using
> > &#
On 4 jun, 12:10, Roald wrote:
> On 3 jun, 19:33, Luke Plant wrote:
> > On Thursday 03 June 2010 08:59:31 Roald wrote:
> > > > One reason against this is it makes it harder to re-use other
> > > > views from within the View.
> > > I don't really
On 16 jun, 15:45, Ben Firshman wrote:
> The request is passed round so methods look like views to decorators.
> Magically dropping it for decorators seems a bit scary. :/
Just brainstorming: couldn't you have View derive from HttpRequest?
Then you get a request object as the first parameter of m
On 17 jun, 12:16, Patryk Zawadzki wrote:
> On Thu, Jun 17, 2010 at 11:53 AM, Roald wrote:
> > On 16 jun, 15:45, Ben Firshman wrote:
> >> The request is passed round so methods look like views to decorators.
> >> Magically dropping it for decorators seems
On 17 jun, 15:32, Tom Evans wrote:
> 1) With inheritance, you should be able to say Derived is-a Base,
I agree very much.
> eg
> 'a Car is-a Vehicle'. A view is NOT a response, however you wrap it
> up. A view is a generator that when called with a request, results in
> a response, whether it is
ure 'ModelView' is the right name for this, since not the
class itself but its requesthandler properties are the actual views.
On the other hand, the name is too nice not to be used.
- I'm no fan of 'class Meta' myself, but I've chosen it here to be
compatible with Mode
o class based generic views; I don't know if it should
actually replace them, or that it's more of a special-case thing (I
think the first). The requesthandler decorator, I think, is relevant
to this thread in either case.
Looking forward to your opinions!
Cheers, Roald
--
You receiv
atible way.
Opinions?
Cheers, Roald
--
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...@g
On Nov 16, 8:40 pm, ptone wrote:
> On Nov 16, 1:12 am, Roald wrote:
>
> > Hi all,
>
> > Can anybody explain why template tag libraries are loaded from
> > *inside* a template? The more I work with them, the more I get the
> > feeling that specifying which
On Nov 17, 12:05 am, Luke Plant wrote:
> From my perspective, putting the template tag libraries in the view is
> absolutely the wrong thing to do, for a number of reasons:
>
> 1) If I'm reading a template and come across a template tag I don't
> understand, I have to go and find the view it is ca
On Nov 17, 8:02 am, Stephen Burrows
wrote:
> I second what Luke and Russ have already said.
>
> If what you're interested in is a way to securely allow users to enter
> template code into the database, you can just write a custom field
> that validates its input for security problems.
>
> Here's
view (IMHO)
- It conforms to standard naming: a URL addresses a resource
- Methods like 'GET', 'POST', 'PUT', 'DELETE' make sense as attributes
of a resource (handle)
- django.resources is shorter than django.class_based_views ;-)
I hope this makes sense, p
ks regardless of
whether A.c exists
I'm curious if other people would be interested in such a feature, or
maybe if something alike or better already exists, and whether there
are downsides that I miss.
Cheers, Roald
--
You received this message because you are subscribed to the Google
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
#x27;.
From an implementational (SQL) standpoint, this seems logical, but
from an OO standpoint, it surely doesn't. I would expect an empty
queryset as a result, or maybe even some exception. Is the current
behavior a (conscious) choice/feature, or a bug?
Cheers, Roald
--
You received this mes
_named_block field_name %}
{{ block.super }}{# refers to the
dynamically_named_block #}
{% enddynamically_named_block %}
{% endfor %}
{% endblock fields %}
{% endblock %}
{% endwith %}
Just brainstorming... let me know what you think
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,
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
in this approach?
Cheers, Roald
--
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...
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
derive from it. Like::
class MyView(View):
@classonlymethod
def as_view(cls, *args, **kwargs):
return login_required(super(MyView, cls).as_view(*args,
**kwargs))
Cheers, Roald
--
You received this message because you are subscribed to the Google Groups "Djan
my_model = ForeignKey('MyModel')
comment = CharField(max_length=100, blank=True)
class MyModel(Model):
users = ManyToManyField(User, through=R, null=True)
m = MyModel.objects.create()
u = User.objects.create_user('roald', 'downa...@gmail.com',
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
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
roach is a bit harder to estimate).
Cheers, Roald
On Sep 17, 2011, at 4:32 AM, Alex Gaynor wrote:
On Fri, Sep 16, 2011 at 10:27 PM, Donald Stufft > wrote:
unittest.skip isn't a Mixin, it turns the class into an exception
and raises it.
It doesn't *turn* a class into anything, i
27 matches
Mail list logo
