Re: Feature proposal: escape hatch for colliding template syntax in django templates
> If we're going to do this, could we also look at deprecating the
> 'templatetag' template tag? There are a couple cases a 'verbatim' tag
> wouldn't cover that 'templatetag' wouldn't, but I'm kinda hard-pressed
> to think of when they'd ever come up in reality.
+1 for this. I for one don't even use {% templatetag %}, as {{ "{{" }}
is so much easier.
Besides adding some non-rendering-tag I would love to see a
rendering-tag to allow two way rendering for caching/performance
reasons, example:
Usage:
{% render %}{% cache ... %}
this will be cached content: FOOBAR {{ some_var }}
this will not be cached content: {% verbatim %}{{ user }}{% verbatim
%}
{% endcache %}{% endrender %}
I could even provide some code for a {% render %}-tag, as I use
something like this in production.
David
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Feature proposal: escape hatch for colliding template syntax in django templates
On 20/10/10 02:40, Stephen Kelly wrote:
Sorry. Sent too early. All thumbs today. Consider these examples:
{% verbatim "%} %}" %}
(That is, "%} %}" in a verbatim-no-end tag)
{% verbatim %} %} %} {% endverbatim %}
(That is, " %} %} " wrapped in verbatim tags)
The current lexer uses regexps to find tokens like that. It would need to be
completely rewritten/redesigned to handle these cases.
All the best,
Steve.
Are you sure? There's no nesting here, so I'm reasonably sure this could
be a regular language, though I don't want to sit down and prove that.
Instead, as an engineer, a regex that can distinguish the two:
In [38]: re.split(re.compile(r'{% \s* ( (?: [\w\-_\s]+ ) (?: \s* \"
[\w\-_\s%}{]+ \" \s*)* ) \s* %}', re.VERBOSE), '{% foo "%}" %} {% endfoo
%}')
Out[38]: ['', 'foo "%}" ', ' ', 'endfoo ', '']
In [39]: re.split(re.compile(r'{% \s* ( (?: [\w\-_\s]+ ) (?: \s* \"
[\w\-_\s%}{]+ \" \s*)* ) \s* %}', re.VERBOSE), '{% foo %} %} {% endfoo %}')
Out[39]: ['', 'foo ', ' %} ', 'endfoo ', '']
(the key here is asserting the even number of quote marks, something a
regular language is capable of expressing)
It's a bit early in the morning for in-depth regexes, but that seems to
show that it is _probably_ possible. Whether we should be continuing to
use the regex-based parser or moving to a proper lexing/tokenising one
is a different question, but if we did a parser rewrite it wouldn't be
able to land until 1.4 now, I imagine.
Andrew
--
You received this message because you are subscribed to the Google Groups "Django
developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: new class based views
Awesome, thank you! I've asked about @login_required and class based views in django-users, and I'd like to ask here: are something like LoginRequiredMixin's planned? -- Best Regards, Valentin Golev Lead Developer r00, http://r00.ru http://valyagolev.net +7 921 789 0895, avaiable 12:00-18:00 MSK On Wed, Oct 20, 2010 at 4:36 AM, Russell Keith-Magee wrote: > On Wed, Oct 20, 2010 at 1:25 AM, Valentin Golev wrote: >> Hello, >> >> I'm trying to use brand new Class Based Views and I have a question >> about implementation. >> >> Let's take a look at SingleObjectMixin.get_object(): >> http://code.djangoproject.com/browser/django/trunk/django/views/generic/detail.py >> >> Why does it use function arguments, and not self.kwargs, while, for >> example, View.get() or post() methods use instance variables? >> >> Is it going to change? I'm just curious. I understand that since this >> is not the release, API is subject to change, so I'd like to know is >> it going to change and how. > > Good catch! I've just made a change (r14292) to make get_object() more > consistent with the rest of the class-based view API, dropping the > (pk=None, slug=None, **kwargs) arguments in favor of using > self.kwargs. I've also added formal API documentation for > get_object(), which was omitted for some reason. > > Thanks for the feedback! > > Yours, > Russ Magee %-) > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-develop...@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Ordering Check in django/core/management/validation.py
Hi, I'm not sure I'm following protocol here, but here it goes... django/core/management/validation.py, both in the current trunk and in 1.2.3 It says in the accompanying comment: # Skip ordering in the format field1__field2 (FIXME: checking # this format would be nice, but it's a little fiddly). However, the actual check is for only one "_" Which leads fieldnames which contain underscores to not be checked for ordering; The patch would be something like this: 260c260 < if '__' in field_name: --- > if '_' in field_name: Good luck, Klaas -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: new class based views
On Wed, Oct 20, 2010 at 6:01 PM, Valentin Golev wrote: > Awesome, thank you! > > I've asked about @login_required and class based views in > django-users, and I'd like to ask here: are something like > LoginRequiredMixin's planned? No, nothing like that is planned. This is a situation were decorators will be a better match in the general case, because login redirection can usually be transparently wrapped around a view. You should be able to use decorators on class based views in the same way that you use them on normal function views. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Ordering Check in django/core/management/validation.py
On Wed, Oct 20, 2010 at 6:43 PM, Klaas van Schelven wrote: > Hi, > > I'm not sure I'm following protocol here, but here it goes... The best way to report this is to open a ticket [1] which describes the problem in detail (which is what you've done here). This ensure that we have a formal way of tracking that the issue exists, when it is resolved, etc. For bonus points, if you're able to generate a source code diff that contains the fix you propose, that will make it easier for us to make the change. For double bonus points, if your diff includes a test case that verifies the problem exists, and that your patch fixes it, you make it very easy for us to make the change. Tests for model validation usually live in tests/modeltests/invalid_models, which is a list of models known to have model problems, followed by a list of the problems that Django reports. [1] http://code.djangoproject.com/simpleticket Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: new class based views
As far as I know, I can just say: @login_required class MyView(View): # ... since it will wrap __init__ I need either to create a decorator for decorators: @on_dispatch(login_required) class MyView(View): or decorate result of MyView().as_view(). Maybe I'm wrong. I think it will be great to add something about it to docs, since decorators is extremely wide-used feature. -- Best Regards, Valentin Golev Lead Developer r00, http://r00.ru http://valyagolev.net +7 921 789 0895, avaiable 12:00-18:00 MSK On Wed, Oct 20, 2010 at 2:59 PM, Russell Keith-Magee wrote: > On Wed, Oct 20, 2010 at 6:01 PM, Valentin Golev wrote: >> Awesome, thank you! >> >> I've asked about @login_required and class based views in >> django-users, and I'd like to ask here: are something like >> LoginRequiredMixin's planned? > > No, nothing like that is planned. This is a situation were decorators > will be a better match in the general case, because login redirection > can usually be transparently wrapped around a view. > > You should be able to use decorators on class based views in the same > way that you use them on normal function views. > > Yours, > Russ Magee %-) > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-develop...@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: new class based views
Almost everything I'm talking about right now is from this thread:
http://groups.google.com/group/django-users/browse_frm/thread/5239e284b5c285d5/a2676f257d37cf85#a2676f257d37cf85
("login_required and new class based views" in django-users in case
the link doesnt work.)
--
Best Regards,
Valentin Golev
Lead Developer
r00, http://r00.ru
http://valyagolev.net
+7 921 789 0895, avaiable 12:00-18:00 MSK
On Wed, Oct 20, 2010 at 3:05 PM, Valentin Golev wrote:
> As far as I know, I can just say:
>
> @login_required
> class MyView(View):
> # ...
>
> since it will wrap __init__
>
> I need either to create a decorator for decorators:
> @on_dispatch(login_required)
> class MyView(View):
>
> or decorate result of MyView().as_view().
>
> Maybe I'm wrong. I think it will be great to add something about it to
> docs, since decorators is extremely wide-used feature.
>
> --
> Best Regards,
> Valentin Golev
> Lead Developer
> r00, http://r00.ru
>
> http://valyagolev.net
> +7 921 789 0895, avaiable 12:00-18:00 MSK
>
>
>
> On Wed, Oct 20, 2010 at 2:59 PM, Russell Keith-Magee
> wrote:
>> On Wed, Oct 20, 2010 at 6:01 PM, Valentin Golev wrote:
>>> Awesome, thank you!
>>>
>>> I've asked about @login_required and class based views in
>>> django-users, and I'd like to ask here: are something like
>>> LoginRequiredMixin's planned?
>>
>> No, nothing like that is planned. This is a situation were decorators
>> will be a better match in the general case, because login redirection
>> can usually be transparently wrapped around a view.
>>
>> You should be able to use decorators on class based views in the same
>> way that you use them on normal function views.
>>
>> Yours,
>> Russ Magee %-)
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers" group.
>> To post to this group, send email to django-develop...@googlegroups.com.
>> To unsubscribe from this group, send email to
>> django-developers+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/django-developers?hl=en.
>>
>>
>
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: new class based views
On Wed, Oct 20, 2010 at 7:05 PM, Valentin Golev wrote: > As far as I know, I can just say: > > @login_required > class MyView(View): > # ... > > since it will wrap __init__ > > I need either to create a decorator for decorators: > @on_dispatch(login_required) > class MyView(View): > > or decorate result of MyView().as_view(). > > Maybe I'm wrong. I think it will be great to add something about it to > docs, since decorators is extremely wide-used feature. As I've commented on the django-users thread, Django already provides method_decorator(), which provides a way to decorate the dispatch function (or any individual get/post etc HTTP method) on a class-based view. The other simple way to decorate a view is to decorate the result of the as_view() call in the URL pattern -- i.e., instead of deploying: MyView.as_view() deploy: login_required(MyView.as_view()) A class decorator (and/or a wrapper function for turning decorators into class decorators) is also an interesting idea. However, unlike method_decorator(), a class_decorator() would need to be view-specific, since it needs to modify the class it wraps in a specific way, rather than the completely generic approach that method_decorator() can take. Regardless, your point about documenting these approaches is well taken. It isn't immediately obvious how decoration should work in a class-based world. If you open a ticket for this, that will help make sure that this idea isn't forgotten. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: new class based views
I think class decorator for views only is a great idea, because it will be: a) just like with old view functions decorators b) does not require any method overrides/imports into urls.py/explicit transformations in views.py I'd like Django to have a decorator for turning old decorators into decorators for class based views. I've hardly seen @login_required and lots of other common decorators not used in the view context, so why avoid being attached to Django views interface, since we already made up our minds about having such an interface. So I think, both tickets - for docs and for "@on_dispatch()" decorators - are worth it. -- Best Regards, Valentin Golev Lead Developer r00, http://r00.ru http://valyagolev.net +7 921 789 0895, avaiable 12:00-18:00 MSK On Wed, Oct 20, 2010 at 3:25 PM, Russell Keith-Magee wrote: > On Wed, Oct 20, 2010 at 7:05 PM, Valentin Golev wrote: >> As far as I know, I can just say: >> >> @login_required >> class MyView(View): >> # ... >> >> since it will wrap __init__ >> >> I need either to create a decorator for decorators: >> @on_dispatch(login_required) >> class MyView(View): >> >> or decorate result of MyView().as_view(). >> >> Maybe I'm wrong. I think it will be great to add something about it to >> docs, since decorators is extremely wide-used feature. > > As I've commented on the django-users thread, Django already provides > method_decorator(), which provides a way to decorate the dispatch > function (or any individual get/post etc HTTP method) on a class-based > view. > > The other simple way to decorate a view is to decorate the result of > the as_view() call in the URL pattern -- i.e., instead of deploying: > > MyView.as_view() > > deploy: > > login_required(MyView.as_view()) > > A class decorator (and/or a wrapper function for turning decorators > into class decorators) is also an interesting idea. However, unlike > method_decorator(), a class_decorator() would need to be > view-specific, since it needs to modify the class it wraps in a > specific way, rather than the completely generic approach that > method_decorator() can take. > > Regardless, your point about documenting these approaches is well > taken. It isn't immediately obvious how decoration should work in a > class-based world. If you open a ticket for this, that will help make > sure that this idea isn't forgotten. > > Yours, > Russ Magee %-) > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-develop...@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Feature proposal: escape hatch for colliding template syntax in django templates
Am 20.10.2010 um 10:40 schrieb Andrew Godwin:
> On 20/10/10 02:40, Stephen Kelly wrote:
>> Sorry. Sent too early. All thumbs today. Consider these examples:
>>
>> {% verbatim "%} %}" %}
>>
>> (That is, "%} %}" in a verbatim-no-end tag)
>>
>> {% verbatim %} %} %} {% endverbatim %}
>>
>> (That is, " %} %} " wrapped in verbatim tags)
>>
>> The current lexer uses regexps to find tokens like that. It would need to be
>> completely rewritten/redesigned to handle these cases.
>>
>> All the best,
>>
>> Steve.
>>
>>
>
> Are you sure? There's no nesting here, so I'm reasonably sure this could be a
> regular language, though I don't want to sit down and prove that.
A verbatim tag would at least introduce ambiguity:
{% verbatim %}{% endverbatim %}{% verbatim %}{% endverbatim %}
This could be parsed as [Verbatim(""), Verbatim("")] or [Verbatim("{%
endverbatim %}{% verbatim %}")].
For the inline case, e.g. {% verbatim "%}" %}, it might be cleaner to just
allow template tag delimiters in strings inside var nodes - the lexer would
have to be modified anyway:
{{ '%}' }} or even {{ foo|prefix:'{%'|suffix:'%}' }}
__
Johannes
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Model proxy instance does not equal the respective model instance
Continuing from... http://code.djangoproject.com/ticket/14492 > the real issue here is "What is a Proxy", and "what is equality" I agree, that is the real issue. I based most of my reasoning off of what the docs already state in that a proxy model can be written to extend the behavior of the model being proxied, i.e. the data model cannot be changed. That being said, I feel the default behavior when dealing with equality, other data related things... should inherit from there parent. If there is a need to override this behavior, I am sure other hooks can be implemented to customize proxy models differently then there parent. With regards to my primary issue of equality, in this context two objects are being compared to determine whether they represent the same row of data. It seems less likely to compare two model objects to only be interested in whether they are equal data structures. Regarding permissions, the arguments presented in http://code.djangoproject.com/ticket/11154 all can be accomplished with writing a custom manager for the proxy model or writing a custom ModelAdmin class for the admin. I agree with Malcolm that a proxy model's permission should shadow its parent. On Oct 19, 9:08 am, Byron wrote: > Added ticket and patch:http://code.djangoproject.com/ticket/14492 > > On Oct 17, 12:00 pm, Byron wrote: > > > > > > > > > I came across an issue when comparing a model proxy instance and a > > model instance, that is: > > > obj1 = Entry.objects.get(id=1) > > obj2 = EntryProxy.objects.get(id=1) > > > obj1 == obj2 # False > > > This I feel is a bug and the culprit is in ``Model.__eq__`` where it > > tests to see if the object being compared against is an instance of > > the same class of the Model itself.. which will always be false for > > proxy models being compared to there non-proxied instance > > counterparts. It should test if it is a proxy and whether the object > > is an instance of the parent class as well. > > > Was this a design decision or overlooked? -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: new class based views
On Wed, 2010-10-20 at 19:25 +0800, Russell Keith-Magee wrote: > A class decorator (and/or a wrapper function for turning decorators > into class decorators) is also an interesting idea. An argument against this is "one way to do it". If I look at a class and want to know what decorators are applied, if would be nice if there was only one place to look. I guess that that one place could be the class rather than the 'dispatch' method, if we encourage that practice, but that pattern might be hard to encourage since class-decoration is less obvious (and certainly much less well established in the Django code base) than method decoration. Luke -- If you can't answer a man's arguments, all is not lost; you can still call him vile names. (Elbert Hubbard) Luke Plant || http://lukeplant.me.uk/ -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: new class based views
On 20 October 2010 15:59, Luke Plant wrote: > On Wed, 2010-10-20 at 19:25 +0800, Russell Keith-Magee wrote: > >> A class decorator (and/or a wrapper function for turning decorators >> into class decorators) is also an interesting idea. > > An argument against this is "one way to do it". If I look at a class > and want to know what decorators are applied, if would be nice if there > was only one place to look. I guess that that one place could be the > class rather than the 'dispatch' method, if we encourage that practice, > but that pattern might be hard to encourage since class-decoration is > less obvious (and certainly much less well established in the Django > code base) than method decoration. OTOH, it'a annoying to have to write an dispatch() method with a super inside (which effectively does nothing), just to apply a decorator. -- Łukasz Rekucki -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: new class based views
Well, since we are already using class Mixins for extending View functionality, we can try to turn decorators into mixins. Having two ways to add some functionality to class (decorators and mixins) can be somewhat uncomfortable. I had some doubts if mixins can act as a "wrappers" to defined functions, but, as I was told, these doubts were based on my poor understanding of how "super()" and mixins work. I totally agree with Łukasz about annoyance of decorating a dispatch() function. -- Best Regards, Valentin Golev Lead Developer r00, http://r00.ru http://valyagolev.net +7 921 789 0895, avaiable 12:00-18:00 MSK On Wed, Oct 20, 2010 at 5:59 PM, Luke Plant wrote: > On Wed, 2010-10-20 at 19:25 +0800, Russell Keith-Magee wrote: > >> A class decorator (and/or a wrapper function for turning decorators >> into class decorators) is also an interesting idea. > > An argument against this is "one way to do it". If I look at a class > and want to know what decorators are applied, if would be nice if there > was only one place to look. I guess that that one place could be the > class rather than the 'dispatch' method, if we encourage that practice, > but that pattern might be hard to encourage since class-decoration is > less obvious (and certainly much less well established in the Django > code base) than method decoration. > > Luke > > -- > If you can't answer a man's arguments, all is not lost; you can > still call him vile names. (Elbert Hubbard) > > Luke Plant || http://lukeplant.me.uk/ > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-develop...@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: new class based views
On Wed, Oct 20, 2010 at 9:59 PM, Luke Plant wrote: > On Wed, 2010-10-20 at 19:25 +0800, Russell Keith-Magee wrote: > >> A class decorator (and/or a wrapper function for turning decorators >> into class decorators) is also an interesting idea. > > An argument against this is "one way to do it". If I look at a class > and want to know what decorators are applied, if would be nice if there > was only one place to look. I guess that that one place could be the > class rather than the 'dispatch' method, if we encourage that practice, > but that pattern might be hard to encourage since class-decoration is > less obvious (and certainly much less well established in the Django > code base) than method decoration. I'm not sure that argument holds up. Right now, we already have 2 ways to do it - you can decorate the view function at time of definition, and you can decorate when it is included in the URL pattern. The class-based view case is also complicated by the common usage pattern. Consider a prototypical view: class MyView(View): def get(self, request, *args, **kwargs): ... def post(self, request, *args, **kwargs): ... You don't have to define dispatch or as_view -- the two places that can be decorated to provide class-wide behavior. You could decorate both get *and* post -- which may be a good approach in some cases (say you want all GETs to be allowed, but POSTs to be login protected) -- but it's an unusual duplication to require for the common case. You could also decorate the MyView.as_view() line in the URL pattern, but that doesn't enforce the decorator for every use. There's no simple direct analog of the "make sure every access to this view is decorated". To me, a class-view-decorator seems like a way to express the existing use case. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: new class based views
Created a ticket for this: http://code.djangoproject.com/ticket/14512 On 20 October 2010 16:13, Russell Keith-Magee wrote: > On Wed, Oct 20, 2010 at 9:59 PM, Luke Plant wrote: >> On Wed, 2010-10-20 at 19:25 +0800, Russell Keith-Magee wrote: >> >>> A class decorator (and/or a wrapper function for turning decorators >>> into class decorators) is also an interesting idea. >> >> An argument against this is "one way to do it". If I look at a class >> and want to know what decorators are applied, if would be nice if there >> was only one place to look. I guess that that one place could be the >> class rather than the 'dispatch' method, if we encourage that practice, >> but that pattern might be hard to encourage since class-decoration is >> less obvious (and certainly much less well established in the Django >> code base) than method decoration. > > I'm not sure that argument holds up. Right now, we already have 2 ways > to do it - you can decorate the view function at time of definition, > and you can decorate when it is included in the URL pattern. > > The class-based view case is also complicated by the common usage > pattern. Consider a prototypical view: > > class MyView(View): > def get(self, request, *args, **kwargs): > ... > def post(self, request, *args, **kwargs): > ... > > You don't have to define dispatch or as_view -- the two places that > can be decorated to provide class-wide behavior. You could decorate > both get *and* post -- which may be a good approach in some cases (say > you want all GETs to be allowed, but POSTs to be login protected) -- > but it's an unusual duplication to require for the common case. You > could also decorate the MyView.as_view() line in the URL pattern, but > that doesn't enforce the decorator for every use. > > There's no simple direct analog of the "make sure every access to this > view is decorated". To me, a class-view-decorator seems like a way to > express the existing use case. > > Yours, > Russ Magee %-) > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-develop...@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > -- Łukasz Rekucki -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Ordering Check in django/core/management/validation.py
http://code.djangoproject.com/ticket/14513 Now give me my bonus points :-) On Oct 20, 1:05 pm, Russell Keith-Magee wrote: > On Wed, Oct 20, 2010 at 6:43 PM, Klaas van Schelven > > wrote: > > Hi, > > > I'm not sure I'm following protocol here, but here it goes... > > The best way to report this is to open a ticket [1] which describes > the problem in detail (which is what you've done here). This ensure > that we have a formal way of tracking that the issue exists, when it > is resolved, etc. > > For bonus points, if you're able to generate a source code diff that > contains the fix you propose, that will make it easier for us to make > the change. > > For double bonus points, if your diff includes a test case that > verifies the problem exists, and that your patch fixes it, you make it > very easy for us to make the change. > > Tests for model validation usually live in > tests/modeltests/invalid_models, which is a list of models known to > have model problems, followed by a list of the problems that Django > reports. > > [1]http://code.djangoproject.com/simpleticket > > Yours, > Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Proposal: A better way to handle unic�de in messag es, etc
I was trying some things out, and I noticed that it isn't actually
possible (without using a char-code and converting it) to put
something like ° (degree symbol) into a "message".
Example:
this code:
messages.info(request, request.GET.get('symbol'))
with this URL:
http://127.0.0.1:8080/?symbol=%BO
will result in:
UnicodeEncodeError at /
('ascii', u'\ufffd', 0, 1, 'ordinal not in range(128)')
Perhaps this is beyond what a framework should deal with, but if
possible, it'd be handy. I built a little site for my wife using
PostgreSQL and if she puts a trademark symbol into a page title, the
success message that should come up on the next (which includes the
title) page causes an exception.
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
contrib.staticfiles app concerns
Hi, first of all, sorry for chiming in so late. It seems like this has been discussed in May, already, but I didn't follow the discussion back then. Today the staticfiles contrib app was committed to trunk. This got me wondering: Wasn't there recently a discussion about how "contrib" is a bad idea and all apps should either be in core or live as separate projects? Is staticfiles really a core app? Even if it is a core app, does it do its job well enough to be in contrib? I do agree that such an app is critical for practically all web projects and the documentation even says: """ For small projects, this [static files management] isn't a big deal, because you can just keep the media somewhere your web server can find it. However, in bigger projects -- especially those comprised of multiple apps -- dealing with the multiple sets of static files provided by each application starts to get tricky. """ So like the docs say, staticfiles seems to target "bigger projects". However, what staticfiles does has almost nothing to do with "bigger project" asset management. Just look at the features grid on djangopackages (disclaimer: I'm the author of django-mediagenerator and I maintain that grid): http://djangopackages.com/grids/g/asset-managers/ It's obvious that django-staticfiles has none of the critical features: * It doesn't combine your CSS/JS files. * It doesn't compress them. * It doesn't support CSS compilers like Sass or Less. * It doesn't support versioning of CSS, JS, and images. * Because of the lack of versioning the staticfiles view doesn't (and can't) support proper caching which means for every single visited page the browser will make unnecessary "if-modified-since" roundtrips to the very slow runserver. These unnecessary HTTP roundtrips make it very painful to work even on medium sized projects (unless combined with a local dev http server like Apache). * Finally, staticfiles doesn't auto-regenerate the assets when they are changed. This makes development extremely painful and error-prone because you have to "manage.py collectstatic" every time you make a little change to your JS or CSS code (and that's really easy to forget). >From that point of view, staticfiles is only useful for small hobby projects. So, why was this app added to Django? Most projects are better off using a different solution, anyway. BTW, I noticed a bug in the staticfiles view: It checks for "if settings.DEBUG", but that should be "if not settings.DEBUG". Also, staticfiles doesn't index "media" folders although the admin uses "media" instead of "static". Why not follow the existing scheme? Bye, Waldemar Kornewald -- Django on App Engine, MongoDB, ...? Browser-side Python? It's open-source: http://www.allbuttonspressed.com/blog/django -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: new class based views
On Wed, 2010-10-20 at 16:05 +0200, Łukasz Rekucki wrote: > OTOH, it's annoying to have to write an dispatch() method with a super > inside (which effectively does nothing), just to apply a decorator. That's a good point I hadn't thought of, as are Russell's other points. Just to put it on the table, another option we thought of at one point was to have a 'decorators' attribute on the class, which is a list of decorators that is applied by the as_view() method. It would in theory allow you to add decorators to either end of the set of decorators that are applied, something like this: class MyView(SomeOtherView): decorators = SomeOtherView.decorators + [my_dec_1, my_dec_2] It gets a bit trickier with multiple inheritance. I don't know if that would be too much of a big deal - I would imagine that most of the mixin classes would not be providing decorators. But then my imagination is probably limited. Luke -- If you can't answer a man's arguments, all is not lost; you can still call him vile names. (Elbert Hubbard) Luke Plant || http://lukeplant.me.uk/ -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Proposal: A better way to handle unicode in messages, etc
On Wed, 2010-10-20 at 09:50 -0700, Yo-Yo Ma wrote:
> I was trying some things out, and I noticed that it isn't actually
> possible (without using a char-code and converting it) to put
> something like ° (degree symbol) into a "message".
>
> Example:
>
> this code:
> messages.info(request, request.GET.get('symbol'))
>
> with this URL:
> http://127.0.0.1:8080/?symbol=%BO
>
> will result in:
> UnicodeEncodeError at /
> ('ascii', u'\ufffd', 0, 1, 'ordinal not in range(128)')
This would definitely be classed as a bug. But I for one can't
reproduce it. Assuming your default charset is UTF-8, your URL should
actually contain '%C2%B0'. With that change, your example code works
perfectly on a page I tried. (Without it, I still don't get an
exception).
Luke
--
If you can't answer a man's arguments, all is not lost; you can
still call him vile names. (Elbert Hubbard)
Luke Plant || http://lukeplant.me.uk/
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Proposal: A better way to handle unicode in messages, etc
request.GET should convert %codes into their appropriate characters, the
problem is likely that messages.info is expecting an ascii string, not
unicode.
messages.info(request, unicode(request.GET.get('symbol'),
errors='replace'))
Will replace the degree symbol with a ?, if I remember correctly.
Otherwise you'll need to re-encode it using something else, like url
encoding, and decode it again before displaying.
--
Michael
On Wed, 2010-10-20 at 18:57 +0100, Luke Plant wrote:
> On Wed, 2010-10-20 at 09:50 -0700, Yo-Yo Ma wrote:
> > I was trying some things out, and I noticed that it isn't actually
> > possible (without using a char-code and converting it) to put
> > something like ° (degree symbol) into a "message".
> >
> > Example:
> >
> > this code:
> > messages.info(request, request.GET.get('symbol'))
> >
> > with this URL:
> > http://127.0.0.1:8080/?symbol=%BO
> >
> > will result in:
> > UnicodeEncodeError at /
> > ('ascii', u'\ufffd', 0, 1, 'ordinal not in range(128)')
>
> This would definitely be classed as a bug. But I for one can't
> reproduce it. Assuming your default charset is UTF-8, your URL should
> actually contain '%C2%B0'. With that change, your example code works
> perfectly on a page I tried. (Without it, I still don't get an
> exception).
>
> Luke
>
> --
> If you can't answer a man's arguments, all is not lost; you can
> still call him vile names. (Elbert Hubbard)
>
> Luke Plant || http://lukeplant.me.uk/
>
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Gentle Proposal: add 'render' shortcut in 1.3
Hi all, I'm talking about this ticket: http://code.djangoproject.com/ticket/12816 With class-based views landed and the deprecation of django.views.generic.simple (and direct_to_template in particular) there won't be simple and undeprecated shortcut for render_to_response. So please add the 'render' shortcut in 1.3. direct_to_template was always a hack (when used as render_to_response replacement) because it 'unrolls' callables and 1.3 seems to be a perfect place to replace small hacks for proper solutions. Please take my proposal as a gentle reminder :) If there are reasons for this not to be in 1.3 (developer time, unresolved questions, etc.) then fine, but it'll be pity if this feature won't be in next release just because we forget about it. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: contrib.staticfiles app concerns
Hi Waldemar, On Oct 20, 1:40 pm, Waldemar Kornewald wrote: [snip] > However, what staticfiles does has almost nothing to do with "bigger > project" asset management. Just look at the features grid on > djangopackages (disclaimer: I'm the author of django-mediagenerator > and I maintain that grid):http://djangopackages.com/grids/g/asset-managers/ > It's obvious that django-staticfiles has none of the critical features: > * It doesn't combine your CSS/JS files. > * It doesn't compress them. > * It doesn't support CSS compilers like Sass or Less. > * It doesn't support versioning of CSS, JS, and images. > * Because of the lack of versioning the staticfiles view doesn't (and > can't) support proper caching which means for every single visited > page the browser will make unnecessary "if-modified-since" roundtrips > to the very slow runserver. These unnecessary HTTP roundtrips make it > very painful to work even on medium sized projects (unless combined > with a local dev http server like Apache). > * Finally, staticfiles doesn't auto-regenerate the assets when they > are changed. And the "lack" of all of these features is precisely why staticfiles is well suited to contrib, whereas something like mediagenerator is not (even though it may be very useful). Staticfiles has a very specific, well-defined purpose (collecting media files from apps), which fills a major hole in the Django "story" for reusable apps. It does not come with a pile of additional features outside that scope, adding much more code and more areas where people may reasonably disagree on the best implementation. Every feature you list here can easily be provided by a separate app on top of staticfiles. I currently use staticfiles in combination with django_compressor, which provides all these additional features (compression, combining, versioning, auto-regenerating when changed), and the combination works very well. I prefer having separable concerns in separate apps whenever possible, and the tasks performed by staticfiles and compressor are very much separable. > This makes development extremely painful and error-prone > because you have to "manage.py collectstatic" every time you make a > little change to your JS or CSS code (and that's really easy to > forget). In development you generally would not run "manage.py collectstatic" at all; you use the dynamic-serving view instead so changes are reflected instantly. Carl -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Field localize useless
That's probably a poor example. Australian postcodes should be a StringField with a validation constraint ensuring that its 4 digits. Why? Well, there are australian postcodes that start with 0 - Northern Territory - and they're not going to be displayed correctly with ANY reasonable localisation feature. If any application requires a specific integer representation, then they're outside the scope of localisation and their display should be coded specifically. On Oct 19, 6:33 am, Michel Thadeu Sabchuk wrote: > > Consider as an example: Australian postcodes are 4 digit numbers. It's > > entirely reasonable that they might be stored as an IntegerField. But > > it would be completely inappropriate to display an Australian postcode > > withlocalize=True -- as "6,105", rather than "6105". -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Gentle Proposal: add 'render' shortcut in 1.3
On Wed, Oct 20, 2010 at 1:48 PM, Mikhail Korobov wrote: > So please add the 'render' shortcut in 1.3. It's one of the things on my list. If you'd like to make it happen faster, a patch + tests would make it a no-brainer for me. Jacob -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Gentle Proposal: add 'render' shortcut in 1.3
That's great! I'll mark the ticket as assigned for me then. There is an unresolved question in the ticket: "The only hesitation is the relationship with #12815; we should resolve that decision before committing anything for this ticket." #12815 is about introducing TemplateResponse. Is the patch with 'render' shortcut returning just HttpResponse acceptable? I think that TemplateResponse is less useful after class-based views make their way into trunk so 'render' shortcut shouldn't bother returning TemplateResponse. There are ways to reuse view logic (and change view context in particular) now and TemplateResponse (which was a good addition to django 1.2/1.1/1.0) seems to only complicate things in django 1.3. On 21 окт, 01:02, Jacob Kaplan-Moss wrote: > On Wed, Oct 20, 2010 at 1:48 PM, Mikhail Korobov > wrote: > > So please add the 'render' shortcut in 1.3. > > It's one of the things on my list. If you'd like to make it happen > faster, a patch + tests would make it a no-brainer for me. > > Jacob -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: contrib.staticfiles app concerns
I agree with Carl, > Staticfiles has a very specific, well-defined purpose (collecting media > files from apps), which fills a major hole in the Django "story" for > reusable apps. IMHO contrib apps should have the following characteristics (and probably more): * Solves a problem that can be described in one short sentence. * Solves a fundamental problem in web development, including problems involving the reusable app paradigm. * Doesn't restrict the programmer from using other tools to solve the same problem. * Promotes a convention among developers. Staticfiles solves the problem of reusable app media collection and doesn't restrict the developer from using something else. It also promotes the convention of storing media within a "static" directory, which will help adoption of new reusable apps. To me, adding staticfiles to Django was a logical move that will help the community. Just my two cents. Cheers, --Sean -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Gentle Proposal: add 'render' shortcut in 1.3
2010/10/20 Mikhail Korobov : > There is an unresolved question in the ticket: "The only hesitation is > the relationship with #12815; we should resolve that decision before > committing anything for this ticket." > > #12815 is about introducing TemplateResponse. Is the patch with > 'render' shortcut returning just HttpResponse acceptable? I think that > TemplateResponse is less useful after class-based views make their way > into trunk so 'render' shortcut shouldn't bother returning > TemplateResponse. There are ways to reuse view logic (and change view > context in particular) now and TemplateResponse (which was a good > addition to django 1.2/1.1/1.0) seems to only complicate things in > django 1.3. I agree completely with this reasoning - just render returning an HttpResponse is fine, I think. Jacob -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: contrib.staticfiles app concerns
Hi Carl, On Wed, Oct 20, 2010 at 8:55 PM, Carl Meyer wrote: > Hi Waldemar, > > On Oct 20, 1:40 pm, Waldemar Kornewald wrote: > [snip] >> However, what staticfiles does has almost nothing to do with "bigger >> project" asset management. Just look at the features grid on >> djangopackages (disclaimer: I'm the author of django-mediagenerator >> and I maintain that grid):http://djangopackages.com/grids/g/asset-managers/ >> It's obvious that django-staticfiles has none of the critical features: >> * It doesn't combine your CSS/JS files. >> * It doesn't compress them. >> * It doesn't support CSS compilers like Sass or Less. >> * It doesn't support versioning of CSS, JS, and images. >> * Because of the lack of versioning the staticfiles view doesn't (and >> can't) support proper caching which means for every single visited >> page the browser will make unnecessary "if-modified-since" roundtrips >> to the very slow runserver. These unnecessary HTTP roundtrips make it >> very painful to work even on medium sized projects (unless combined >> with a local dev http server like Apache). >> * Finally, staticfiles doesn't auto-regenerate the assets when they >> are changed. > > And the "lack" of all of these features is precisely why staticfiles > is well suited to contrib, whereas something like mediagenerator is > not (even though it may be very useful). Staticfiles has a very > specific, well-defined purpose (collecting media files from apps), > which fills a major hole in the Django "story" for reusable apps. It > does not come with a pile of additional features outside that scope, > adding much more code and more areas where people may reasonably > disagree on the best implementation. In what way does staticfiles make writing reusable apps easier? It merely collects apps' "static" folders. The same thing could be achieved by defining a simple standard: "Put media files in the 'media' folder." and then making sure that all asset managers follow this very simple standard. Then the user is free to choose an asset manager that suits his needs and be happy. The real problem is this: An app that gets shipped with Django needs to fulfill a need of a lot of people and it should be implemented with best practice in mind. If in the end almost every user will switch to a better solution (like you did with django_compressor) then I think it's valid to ask: Why should a tool that only few people want to use be shipped with Django? Isn't a simple standard for asset managers better? > Every feature you list here can easily be provided by a separate app > on top of staticfiles. I currently use staticfiles in combination with > django_compressor, which provides all these additional features > (compression, combining, versioning, auto-regenerating when changed), > and the combination works very well. I prefer having separable > concerns in separate apps whenever possible, and the tasks performed > by staticfiles and compressor are very much separable. That's a funny combination of tools. :) You don't really need django-staticfiles because in your case django_compressor takes care of collecting assets (i.e. it already does staticfiles's job) and keeping the media folder updated. All that django-staticfiles does is serve the files in your media folder. You get the same result with Django's serve() view. Try it. You'll see that django-staticfiles is in fact an unnecessary component in your project. The separation makes everything more difficult (if not impossible) to implement properly. How do you want to connect the very flexible dynamic serving view of django-mediagenerator with the dynamic serving view of staticfiles? There's nothing to be gained from such a separation, especially since the code for collecting files is minimal, anyway. >> This makes development extremely painful and error-prone >> because you have to "manage.py collectstatic" every time you make a >> little change to your JS or CSS code (and that's really easy to >> forget). > > In development you generally would not run "manage.py collectstatic" > at all; you use the dynamic-serving view instead so changes are > reflected instantly. I wish that were the case. The staticfiles documentation says: """ Remember to run :djadmin:`collectstatic` when your media changes; the view only serves static files that have been collected. """ You see, it's a mess. You just didn't notice the mess because you used django_compressor. This only supports my point that staticfiles fails at solving real end-user needs and thus gets replaced with better solutions, anyway. Bye, Waldemar Kornewald -- Django on App Engine, MongoDB, ...? Browser-side Python? It's open-source: http://www.allbuttonspressed.com/blog/django -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googleg
Re: Gentle Proposal: add 'render' shortcut in 1.3
On 20 October 2010 21:57, Jacob Kaplan-Moss wrote: > 2010/10/20 Mikhail Korobov : >> There is an unresolved question in the ticket: "The only hesitation is >> the relationship with #12815; we should resolve that decision before >> committing anything for this ticket." >> >> #12815 is about introducing TemplateResponse. Is the patch with >> 'render' shortcut returning just HttpResponse acceptable? I think that >> TemplateResponse is less useful after class-based views make their way >> into trunk so 'render' shortcut shouldn't bother returning >> TemplateResponse. There are ways to reuse view logic (and change view >> context in particular) now and TemplateResponse (which was a good >> addition to django 1.2/1.1/1.0) seems to only complicate things in >> django 1.3. > > I agree completely with this reasoning - just render returning an > HttpResponse is fine, I think. Both render_to_response() and direct_to_template() have one very annoying flaw: http://code.djangoproject.com/ticket/12669. Please add a "response_class" keyword to your render() function ;). Thanks! -- Łukasz Rekucki -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Gentle Proposal: add 'render' shortcut in 1.3
I think the correct ticket is http://code.djangoproject.com/ticket/9081 and it is in 'almost-wontfix' state now. Yes, it's a great time to either move it to wontfix or mark as accepted and implement alongside with the render shortcut. On 21 окт, 02:05, Łukasz Rekucki wrote: > On 20 October 2010 21:57, Jacob Kaplan-Moss wrote: > > > > > > > 2010/10/20 Mikhail Korobov : > >> There is an unresolved question in the ticket: "The only hesitation is > >> the relationship with #12815; we should resolve that decision before > >> committing anything for this ticket." > > >> #12815 is about introducing TemplateResponse. Is the patch with > >> 'render' shortcut returning just HttpResponse acceptable? I think that > >> TemplateResponse is less useful after class-based views make their way > >> into trunk so 'render' shortcut shouldn't bother returning > >> TemplateResponse. There are ways to reuse view logic (and change view > >> context in particular) now and TemplateResponse (which was a good > >> addition to django 1.2/1.1/1.0) seems to only complicate things in > >> django 1.3. > > > I agree completely with this reasoning - just render returning an > > HttpResponse is fine, I think. > > Both render_to_response() and direct_to_template() have one very > annoying flaw:http://code.djangoproject.com/ticket/12669. Please add > a "response_class" keyword to your render() function ;). Thanks! > > -- > Łukasz Rekucki -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: contrib.staticfiles app concerns
On Wed, Oct 20, 2010 at 3:04 PM, Waldemar Kornewald wrote: > I wish that were the case. The staticfiles documentation says: > > """ > Remember to run :djadmin:`collectstatic` when your media changes; > the view only serves static files that have been collected. > """ I actually wrote that without checking that it's true, and looking at the code I think it's not. It looks like the view does indeed serve files out of the static locations directly. I'll double-check and remove that line from the docs accordingly. > You see, it's a mess. Do you have an alternate proposal? Jacob -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Model proxy instance does not equal the respective model instance
Speaking on a semantic level, a "proxy" is a stand-in acting on behalf of (or in place of) another entity. There is an implied near- equivalence, but inherent in the idea of a proxy is that it is *not* the same as the original. As in the case of assigning a proxy to vote for you in corporate elections: the proxy you delegate your right to vote to is the functional equivalent of you, but they are recognized as not *actually* being you. In my mind the same reasoning applies to Proxy Models. While they are a stand-in for accessing the same underlying data, they may have very different properties (ordering, methods, etc.). So while they may pass a rough equivalence test, they are in specific ways dissimilar. The underlying table/data stored by the model is only one piece of what makes up the sum total of a model. That said, I can certainly see the use case for comparing proxy models as equal to the original model... All the best, - Gabriel On Oct 20, 6:24 am, Byron wrote: > Continuing from...http://code.djangoproject.com/ticket/14492 > > > the real issue here is "What is a Proxy", and "what is equality" > > I agree, that is the real issue. I based most of my reasoning off of > what the docs already state in that a proxy model can be written to > extend the behavior of the model being proxied, i.e. the data model > cannot be changed. That being said, I feel the default behavior when > dealing with equality, other data related things... should inherit > from there parent. If there is a need to override this behavior, I am > sure other hooks can be implemented to customize proxy models > differently then there parent. With regards to my primary issue of > equality, in this context two objects are being compared to determine > whether they represent the same row of data. It seems less likely to > compare two model objects to only be interested in whether they are > equal data structures. > > Regarding permissions, the arguments presented > inhttp://code.djangoproject.com/ticket/11154 > all can be accomplished with writing a custom manager for the proxy > model or writing a custom ModelAdmin class for the admin. I agree with > Malcolm that a proxy model's permission should shadow its parent. > > On Oct 19, 9:08 am, Byron wrote: > > > > > Added ticket and patch:http://code.djangoproject.com/ticket/14492 > > > On Oct 17, 12:00 pm, Byron wrote: > > > > I came across an issue when comparing a model proxy instance and a > > > model instance, that is: > > > > obj1 = Entry.objects.get(id=1) > > > obj2 = EntryProxy.objects.get(id=1) > > > > obj1 == obj2 # False > > > > This I feel is a bug and the culprit is in ``Model.__eq__`` where it > > > tests to see if the object being compared against is an instance of > > > the same class of the Model itself.. which will always be false for > > > proxy models being compared to there non-proxied instance > > > counterparts. It should test if it is a proxy and whether the object > > > is an instance of the parent class as well. > > > > Was this a design decision or overlooked? -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: contrib.staticfiles app concerns
Hi Waldemar, On Oct 20, 4:04 pm, Waldemar Kornewald wrote: > In what way does staticfiles make writing reusable apps easier? It > merely collects apps' "static" folders. The same thing could be > achieved by defining a simple standard: > "Put media files in the 'media' folder." > and then making sure that all asset managers follow this very simple > standard. Then the user is free to choose an asset manager that suits > his needs and be happy. The standard you are asking for is there now, and it's spelled "static." And Django also now provides a functional and useful tool to collect media from that standard location, both dynamically in development and statically in production. If you want to use a different tool for this, you're free to do so. > The real problem is this: An app that gets shipped with Django needs > to fulfill a need of a lot of people and it should be implemented with > best practice in mind. If in the end almost every user will switch to > a better solution (like you did with django_compressor) then I think I did not switch, I used both together. > That's a funny combination of tools. :) > You don't really need django-staticfiles because in your case > django_compressor takes care of collecting assets (i.e. it already > does staticfiles's job) and keeping the media folder updated. All that That is simply not true. django_compressor does not collect media from reusable app media directories. It expects to find all media in COMPRESS_ROOT, a single directory. django-staticfiles solves the separate problem of collecting media from app directories and putting it in that single location. > django-staticfiles does is serve the files in your media folder. You > get the same result with Django's serve() view. Try it. You'll see > that django-staticfiles is in fact an unnecessary component in your > project. No, django-staticfiles serves (in development) or just collects (in production) the files in my project-level static folder, _and all of my app static folders_, and implements an overlay mechanism similar to the app-directories template loader so my project-level static folder can easily override app-provided static files. This is a simple, obvious, and useful mechanism: it is most certainly not an "unnecessary component." > I wish that were the case. The staticfiles documentation says: > > """ > Remember to run :djadmin:`collectstatic` when your media changes; > the view only serves static files that have been collected. > """ The docs are what's wrong here, and should be fixed. > You see, it's a mess. You just didn't notice the mess because you used > django_compressor. This only supports my point that staticfiles fails > at solving real end-user needs and thus gets replaced with better > solutions, anyway. This is a completely false characterization of the situation. I suggest you review again the different and non-overlapping purposes served by staticfiles and a media-compressor. Carl -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Gentle Proposal: add 'render' shortcut in 1.3
On 10/20/2010 11:51 PM, Mikhail Korobov wrote: #12815 is about introducing TemplateResponse. Is the patch with 'render' shortcut returning just HttpResponse acceptable? I think that TemplateResponse is less useful after class-based views make their way into trunk so 'render' shortcut shouldn't bother returning TemplateResponse. There are ways to reuse view logic (and change view context in particular) now and TemplateResponse (which was a good addition to django 1.2/1.1/1.0) seems to only complicate things in django 1.3. Wait!!! Sorry… Hello everyone :-) If I remember correctly TemplateResponse was solving a problem of some middleware wanting to mess with a view context before it's baked into final string representation. This would solve in a good way what now is accomplished by things like @render_to decorator. What I don't understand from your reasoning is how class-based views are going to help here? From what I see only Django-supplied generic views are now class-based and we didn't deprecate simple user view functions. Which means that "render" won't be as useful for them if it wouldn't provide any means to post-process the context and if the context won't be aware of request: these are two main points why people are not happy with render_to_response right now. Mikhail, do you have any actual objections against TemplateResponse or you just don't want to complicate your implementation? If it is the latter then TemplateResponse has been already implemented[1] by Simon Willison. You might just use it. [1]: http://github.com/simonw/django-openid/blob/master/django_openid/response.py -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Gentle Proposal: add 'render' shortcut in 1.3
Hi Ivan! On 21 окт, 03:00, Ivan Sagalaev wrote: > > Wait!!! > > Sorry… Hello everyone :-) > > If I remember correctly TemplateResponse was solving a problem of some > middleware wanting to mess with a view context before it's baked into > final string representation. This would solve in a good way what now is > accomplished by things like @render_to decorator. > > What I don't understand from your reasoning is how class-based views are > going to help here? From what I see only Django-supplied generic views > are now class-based and we didn't deprecate simple user view functions. > Which means that "render" won't be as useful for them if it wouldn't > provide any means to post-process the context and if the context won't > be aware of request: these are two main points why people are not happy > with render_to_response right now. > I see this as several separate specific problems / use cases. 1. Developer writes a view and want to reuse it (e.g. change the context). My assumptions was: a) Class based views are now the recommended way to write reusable views b) The main benefit from TemplateResponse is the ability to reuse view responses. I made this assumption because of the example in #12815, the 'this pattern would be particularly valuable for customising the admin' statement and the original example in your proposal ( http://groups.google.com/group/django-developers/msg/d5df254f01800ee2 ). c) b) can now be achieved by writing a class-based view 2. Developer wants to write a middleware that messes with view context. Class-based views are not going to help here. But I thought it is not nearly as demanded as the first use case. This is useful but not mandatory. That's where my reasoning came from. > Mikhail, do you have any actual objections against TemplateResponse or > you just don't want to complicate your implementation? If it is the > latter then TemplateResponse has been already implemented[1] by Simon > Willison. You might just use it. > > [1]:http://github.com/simonw/django-openid/blob/master/django_openid/resp... Thanks for pointing out the implemented TemplateResponse. No, I haven't actual objections against it and just don't want to complicate the implementation. There was an issue with TemplateResponse approach for Ben Firshman ( http://groups.google.com/group/django-developers/msg/fc9e0f8810d3e784 ) and the ticket is in DDN so it is not as simple as just replace HttpResponse with TemplateResponse. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Admin sends out potentially harmful m2m_changed signals
I'd like to call attention to ticket #6707 [1], which deals with the implementation of ReverseManyRelatedObjectsDescriptor.__set__. Specifically, the problem is that the current implentation takes a very efficient "clear everything and add all the keys back in" approach to managing these relationships. However, since 1.2 gained signals for ManyToMany relationships, this is now a real problem. As reported in #13962 [2] and #14482 [3], rather than sending the correct pre_add/post_add/pre_remove/ post_remove signals based on changes to a ManyToManyField in the admin you instead get a set of pre_clear, post_clear, pre_add, post_add signals containing *all* the keys. This strikes me as having the potential for significant data loss, corruption or duplication if the wrong kind of signals are hooked up. Particularly to the pre/post-clear signals. It would be very easy to see a user accidentally clearing a related table of data with a signal not realizing that the admin application would be sending that clear signal only to add everything back a moment later. So, I want to get some discussion going on the right way to fix the problem. The patch on the ticket uses an extra query and sets to compute the added and removed keys; Malcolm suggested that the admin might independently track the old values to compute what's changed as per #4102. [4] The existing patch has the advantage of being much simpler to implement even if less efficient. What are other people's thoughts? Thanks! - Gabriel [1] http://code.djangoproject.com/ticket/6707 [2] http://code.djangoproject.com/ticket/13962 [3] http://code.djangoproject.com/ticket/14482 [4] http://code.djangoproject.com/ticket/4102 -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Admin sends out potentially harmful m2m_changed signals
I see that this issue was also discussed in #13022 [5], wherein Russ argued that the current signals are technically correct but that solving #6707 would be worthwhile *if* it could be done efficiently. [5] http://code.djangoproject.com/ticket/13022 On Oct 20, 2:45 pm, Gabriel Hurley wrote: > I'd like to call attention to ticket #6707 [1], which deals with the > implementation of ReverseManyRelatedObjectsDescriptor.__set__. > Specifically, the problem is that the current implentation takes a > very efficient "clear everything and add all the keys back in" > approach to managing these relationships. > > However, since 1.2 gained signals for ManyToMany relationships, this > is now a real problem. As reported in #13962 [2] and #14482 [3], > rather than sending the correct pre_add/post_add/pre_remove/ > post_remove signals based on changes to a ManyToManyField in the admin > you instead get a set of pre_clear, post_clear, pre_add, post_add > signals containing *all* the keys. > > This strikes me as having the potential for significant data loss, > corruption or duplication if the wrong kind of signals are hooked up. > Particularly to the pre/post-clear signals. It would be very easy to > see a user accidentally clearing a related table of data with a signal > not realizing that the admin application would be sending that clear > signal only to add everything back a moment later. > > So, I want to get some discussion going on the right way to fix the > problem. The patch on the ticket uses an extra query and sets to > compute the added and removed keys; Malcolm suggested that the admin > might independently track the old values to compute what's changed as > per #4102. [4] The existing patch has the advantage of being much > simpler to implement even if less efficient. > > What are other people's thoughts? > > Thanks! > > - Gabriel > > [1]http://code.djangoproject.com/ticket/6707 > [2]http://code.djangoproject.com/ticket/13962 > [3]http://code.djangoproject.com/ticket/14482 > [4]http://code.djangoproject.com/ticket/4102 -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
generic view fail fast
One benefit with function based views that is lost with generic views is bailing (returning early) conditionally. Say you have a view returns its response if a condition is meet otherwise does some more possible expensive stuff and then returns. Its nice to bail and avoid the expensive stuff. Im not sure of a simple way to do this with generic class based views. Ill give a simple example to make if clear. Example:: class MyView(DetailView): ... def get(self, request, pk, slug): response = super(MyView, self).get(request, pk, slug) if self.object.slug != slug: return redirect(self.object.get_absolute_url()) return response As you can see we are redirecting if the objects slug does not match the one in the url. Of course i can just query based on pk and slug, but that is not the point :) This seems like its currently the best place to put the slug check since self.object gets set in super get but that also generates the http response and that seems wasteful if the slugs don't match. One possible solution is to make self.get_object cache the object then you could call it before super(..., self).get. Another idea which kind of smells, is some sort of way to short circuit the view processing:: def get(request, **kwargs): results = self.get_some_results() return super(..., self).get(request, **kwargs) def get_some_results(): raise FailFast(self.fail_method) ... -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: contrib.staticfiles app concerns
Hi Carl, On Wed, Oct 20, 2010 at 10:53 PM, Carl Meyer wrote: > Hi Waldemar, > > On Oct 20, 4:04 pm, Waldemar Kornewald wrote: >> That's a funny combination of tools. :) >> You don't really need django-staticfiles because in your case >> django_compressor takes care of collecting assets (i.e. it already >> does staticfiles's job) and keeping the media folder updated. All that > > That is simply not true. django_compressor does not collect media from > reusable app media directories. It expects to find all media in > COMPRESS_ROOT, a single directory. django-staticfiles solves the > separate problem of collecting media from app directories and putting > it in that single location. Ah sorry, my assumption was based on the staticfiles documentation which seems to be broken. Also, you're right, the compressor doesn't search app folders. However, quite a few other asset managers do. My primary concern is that with those asset managers you just throw away staticfiles, so unlike django.contrib.sessions which is "totally useful" this app feels more like "maybe useful". I mean, if the real goal is merely to allow for writing reusable apps then staticfiles is not much better than having an official standard and linking to djangopackages, so users can select a standards-compliant asset manager that suits their needs. Bye, Waldemar Kornewald -- Django on App Engine, MongoDB, ...? Browser-side Python? It's open-source: http://www.allbuttonspressed.com/blog/django -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: contrib.staticfiles app concerns
On Wed, Oct 20, 2010 at 10:13 PM, Jacob Kaplan-Moss wrote: > On Wed, Oct 20, 2010 at 3:04 PM, Waldemar Kornewald > wrote: >> I wish that were the case. The staticfiles documentation says: >> >> """ >> Remember to run :djadmin:`collectstatic` when your media changes; >> the view only serves static files that have been collected. >> """ > > I actually wrote that without checking that it's true, and looking at > the code I think it's not. It looks like the view does indeed serve > files out of the static locations directly. I'll double-check and > remove that line from the docs accordingly. Indeed, the documentation is broken. Bye, Waldemar -- Django on App Engine, MongoDB, ...? Browser-side Python? It's open-source: http://www.allbuttonspressed.com/blog/django -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
#14512: Decorating class based views (was Re: new class based views)
On 20 October 2010 19:42, Luke Plant wrote: > On Wed, 2010-10-20 at 16:05 +0200, Łukasz Rekucki wrote: > >> OTOH, it's annoying to have to write an dispatch() method with a super >> inside (which effectively does nothing), just to apply a decorator. > > That's a good point I hadn't thought of, as are Russell's other points. > > Just to put it on the table, another option we thought of at one point > was to have a 'decorators' attribute on the class, which is a list of > decorators that is applied by the as_view() method. It would in theory > allow you to add decorators to either end of the set of decorators that > are applied, something like this: > > class MyView(SomeOtherView): > > decorators = SomeOtherView.decorators + [my_dec_1, my_dec_2] I'm addicted to decorators so I would probably end up with a decorator that adds items to that list :) > > It gets a bit trickier with multiple inheritance. I don't know if that > would be too much of a big deal - I would imagine that most of the mixin > classes would not be providing decorators. But then my imagination is > probably limited. I didn't find a use case for decorating a mixin yet, but i'm only starting to explore (I didn't have this problem in any of my own applications that use CBV). There is a simple pattern to change a decorator into a mixin that should play well with multiple inheritance. On a related note, while writing a class_decorator() I noticed that method_decorator() doesn't work with decorators that set attributes on the view (like csrf_exempt). This is because the decorator is invoked on a closure inside _wrapper() during method call (i.e. during method call, not class creation), while as_view() only sees _wrapper - which has no attributes. -- Łukasz Rekucki -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Proposal: A better way to handle unic�de in me ssages, etc
On Thu, Oct 21, 2010 at 12:50 AM, Yo-Yo Ma wrote: > I was trying some things out, and I noticed that it isn't actually > possible (without using a char-code and converting it) to put > something like ° (degree symbol) into a "message". Sure. Sounds like a bug to me. If you can't call a Django method with unicode content and have it work reliably, that's a bug. Fixing a bug doesn't require a proposal -- it needs a ticket and a patch. Open a ticket and it will go through the normal process. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: new class based views
On Thu, Oct 21, 2010 at 1:42 AM, Luke Plant wrote: > On Wed, 2010-10-20 at 16:05 +0200, Łukasz Rekucki wrote: > >> OTOH, it's annoying to have to write an dispatch() method with a super >> inside (which effectively does nothing), just to apply a decorator. > > That's a good point I hadn't thought of, as are Russell's other points. > > Just to put it on the table, another option we thought of at one point > was to have a 'decorators' attribute on the class, which is a list of > decorators that is applied by the as_view() method. It would in theory > allow you to add decorators to either end of the set of decorators that > are applied, something like this: > > class MyView(SomeOtherView): > > decorators = SomeOtherView.decorators + [my_dec_1, my_dec_2] > > It gets a bit trickier with multiple inheritance. I don't know if that > would be too much of a big deal - I would imagine that most of the mixin > classes would not be providing decorators. But then my imagination is > probably limited. Meh - this seems like reinventing a syntactic wheel to me. Python 2.6 has class decorators. They work in a predictable way, with predictable MRO combination rules. Trying to invent a new class-attribute syntax for class decoration seems like asking for trouble. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: contrib.staticfiles app concerns
On Thu, Oct 21, 2010 at 2:40 AM, Waldemar Kornewald wrote: > Today the staticfiles contrib app was committed to trunk. This got me > wondering: Wasn't there recently a discussion about how "contrib" is a > bad idea and all apps should either be in core or live as separate > projects? Is staticfiles really a core app? Even if it is a core app, > does it do its job well enough to be in contrib? > I thought about this too and had a long thread on Twitter with jezdez about staticfiles. It occurred to me that adding more apps to contrib was kind of a bad idea. I know "everyone" uses admin etc. but I was of the understanding that contrib apps are optional apps for django but staticfiles doesn't seem to be that way. The core 'django.views.static.serve' and 'django.core.context_processors.media' are deprecated in favor of the staticfiles equivalents in contrib. Is the idea that the contrib app is a stepping stone to providing core functionality? i.e. It was put in contrib to maintain backwards compatibility for at least enough time to satisfy the deprecation policy? I'm also getting worried in general about adding more and more functionality to Django that doesn't really *need* to be there. On a seperate topic, it occurred to me that if you wanted to use the same backend for your STATIC_STORAGE as you use for DEFAULT_STORAGE then you'll run into problems if you want to use different options for each. The docs mention django_storages but you'll be hard pressed if you want to store your static and user media in different buckets. It's one of the reasons I added options to the constructor for the s3boto backend (I'm the current maintainer) in django_storages and added a STATIC_STORAGE_KWARGS in my branch of staticfiles on bitbucket. Not sure it was the best solution, but it works. http://bitbucket.org/beproud/django-staticfiles/changeset/f6cdab87d63e -- Ian http://www.ianlewis.org/ -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: contrib.staticfiles app concerns
Ian, > I thought about this too and had a long thread on Twitter with jezdez about > staticfiles. It occurred to me that adding more apps to contrib was kind of a > bad idea. I know "everyone" uses admin etc. but I was of the understanding > that contrib apps are optional apps for django but staticfiles doesn't seem > to be that way. Repeating what I said briefly on Twitter, the reason to extend this ability was to give a better answer to "How does Django help me to manage and deploy static files?" In that sense, the contrib staticfiles app is really just an extension of the tools that Django already provides, the media context processor, the static view and the WSGI Middleware for runserver -- plus a few optional helpers like a template tag, management commands and extensible file finders that work similar to template loaders. All of which are not required to run a Django site. > The core 'django.views.static.serve' and > 'django.core.context_processors.media' are deprecated in favor of the > staticfiles equivalents in contrib. Is the idea that the contrib app is a > stepping stone to providing core functionality? i.e. It was put in contrib to > maintain backwards compatibility for at least enough time to satisfy the > deprecation policy? I'm also getting worried in general about adding more and > more functionality to Django that doesn't really *need* to be there. Moving pieces of code arund is part of the development process and hasn't really been done just for the sake of it. Personally, I don't share your worry about added functionality, as long as it solves real world problems, which staticfiles certainly did for me, as well as for the hundreds of other users, too. > On a seperate topic, it occurred to me that if you wanted to use the same > backend for your STATIC_STORAGE as you use for DEFAULT_STORAGE then you'll > run into problems if you want to use different options for each. The docs > mention django_storages but you'll be hard pressed if you want to store your > static and user media in different buckets. It's one of the reasons I added > options to the constructor for the s3boto backend (I'm the current > maintainer) in django_storages and added a STATIC_STORAGE_KWARGS in my branch > of staticfiles on bitbucket. Not sure it was the best solution, but it works. I would like to stress that using the same storage backend for static files and user generated files is considered bad practice, which is also why I haven't applied your changes in the staticfiles app. It was a distinct design decission to have both kinds of files in different locations and to provide the STATICFILES_STORAGE next to the DEFAUL_STORAGE setting for further extension. I can't comment on the backends in django-storages much since I'm not very familiar with the code, but I assume that it's possible to subclass those storage backends to change the options, as needed. An extended example on djangosnippets.org or in the django-storages docs would cetainly be useful to have of course. If you have any suggestions regarding the staticfiles docs with regard to using other storage backends, I'd appreciate your help. Best, Jannis -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Model proxy instance does not equal the respective model instance
I think that since Proxy models only affect the methods, properties and way the data is used (not the actual underlying data itself), it is appropriate to compare User and UserProxy as equal. To not treat them as equal, you will need to be sure that you never pass a UserProxy object to a 3rd party function that will attempt to compare it to a User object. If you need to in your own code, you can always use isinstance in combination with equality to determine how equal the two objects are. Cheers. Tai. On Oct 21, 7:21 am, Gabriel Hurley wrote: > Speaking on a semantic level, a "proxy" is a stand-in acting on behalf > of (or in place of) another entity. There is an implied near- > equivalence, but inherent in the idea of a proxy is that it is *not* > the same as the original. As in the case of assigning a proxy to vote > for you in corporate elections: the proxy you delegate your right to > vote to is the functional equivalent of you, but they are recognized > as not *actually* being you. > > In my mind the same reasoning applies to Proxy Models. While they are > a stand-in for accessing the same underlying data, they may have very > different properties (ordering, methods, etc.). So while they may pass > a rough equivalence test, they are in specific ways dissimilar. The > underlying table/data stored by the model is only one piece of what > makes up the sum total of a model. > > That said, I can certainly see the use case for comparing proxy models > as equal to the original model... > > All the best, > > - Gabriel > > On Oct 20, 6:24 am, Byron wrote: > > > > > > > > > Continuing from...http://code.djangoproject.com/ticket/14492 > > > > the real issue here is "What is a Proxy", and "what is equality" > > > I agree, that is the real issue. I based most of my reasoning off of > > what the docs already state in that a proxy model can be written to > > extend the behavior of the model being proxied, i.e. the data model > > cannot be changed. That being said, I feel the default behavior when > > dealing with equality, other data related things... should inherit > > from there parent. If there is a need to override this behavior, I am > > sure other hooks can be implemented to customize proxy models > > differently then there parent. With regards to my primary issue of > > equality, in this context two objects are being compared to determine > > whether they represent the same row of data. It seems less likely to > > compare two model objects to only be interested in whether they are > > equal data structures. > > > Regarding permissions, the arguments presented > > inhttp://code.djangoproject.com/ticket/11154 > > all can be accomplished with writing a custom manager for the proxy > > model or writing a custom ModelAdmin class for the admin. I agree with > > Malcolm that a proxy model's permission should shadow its parent. > > > On Oct 19, 9:08 am, Byron wrote: > > > > Added ticket and patch:http://code.djangoproject.com/ticket/14492 > > > > On Oct 17, 12:00 pm, Byron wrote: > > > > > I came across an issue when comparing a model proxy instance and a > > > > model instance, that is: > > > > > obj1 = Entry.objects.get(id=1) > > > > obj2 = EntryProxy.objects.get(id=1) > > > > > obj1 == obj2 # False > > > > > This I feel is a bug and the culprit is in ``Model.__eq__`` where it > > > > tests to see if the object being compared against is an instance of > > > > the same class of the Model itself.. which will always be false for > > > > proxy models being compared to there non-proxied instance > > > > counterparts. It should test if it is a proxy and whether the object > > > > is an instance of the parent class as well. > > > > > Was this a design decision or overlooked? -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Proposal: A better way to handle unic de in messages, etc
Thanks, I'll do that in the morning with a traceback, and steps to reproduce it. On Oct 20, 6:15 pm, Russell Keith-Magee wrote: > On Thu, Oct 21, 2010 at 12:50 AM, Yo-Yo Ma wrote: > > I was trying some things out, and I noticed that it isn't actually > > possible (without using a char-code and converting it) to put > > something like ° (degree symbol) into a "message". > > Sure. Sounds like a bug to me. If you can't call a Django method with > unicode content and have it work reliably, that's a bug. Fixing a bug > doesn't require a proposal -- it needs a ticket and a patch. Open a > ticket and it will go through the normal process. > > Yours, > Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Error email flooding on high traffic production sites
On Sep 30, 8:47 pm, Andrew Wilkinson wrote: > I have a patch in the bug tracker that fixes this exact problem > -http://code.djangoproject.com/ticket/11565. The patch is just over a > year old now so it might not apply that cleanly to the current trunk. Revised patch here (against r13296) -- http://code.djangoproject.com/ticket/11565 -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: contrib.staticfiles app concerns
On Thu, Oct 21, 2010 at 12:25 PM, Jannis Leidel wrote: > Ian, > > > I thought about this too and had a long thread on Twitter with jezdez > about staticfiles. It occurred to me that adding more apps to contrib was > kind of a bad idea. I know "everyone" uses admin etc. but I was of the > understanding that contrib apps are optional apps for django but staticfiles > doesn't seem to be that way. > > Repeating what I said briefly on Twitter, the reason to extend this ability > was to give a better answer to "How does Django help me to manage and deploy > static files?" In that sense, the contrib staticfiles app is really just an > extension of the tools that Django already provides, the media context > processor, the static view and the WSGI Middleware for runserver -- plus a > few optional helpers like a template tag, management commands and extensible > file finders that work similar to template loaders. All of which are not > required to run a Django site. > > > The core 'django.views.static.serve' and > 'django.core.context_processors.media' are deprecated in favor of the > staticfiles equivalents in contrib. Is the idea that the contrib app is a > stepping stone to providing core functionality? i.e. It was put in contrib > to maintain backwards compatibility for at least enough time to satisfy the > deprecation policy? I'm also getting worried in general about adding more > and more functionality to Django that doesn't really *need* to be there. > > Moving pieces of code arund is part of the development process and hasn't > really been done just for the sake of it. Personally, I don't share your > worry about added functionality, as long as it solves real world problems, > which staticfiles certainly did for me, as well as for the hundreds of other > users, too. > I certainly agree it's useful. I use it for my projects. I just don't think it needs to be in core. Anyone that needed this functionality could simply install and use django-staticfiles. For me, adding everything and the kitchen sink to Django with no clear scope is worrysome. Anyway, this part of the conversation at least isn't productive so it's the last you'll hear from me on it. > > On a seperate topic, it occurred to me that if you wanted to use the same > backend for your STATIC_STORAGE as you use for DEFAULT_STORAGE then you'll > run into problems if you want to use different options for each. The docs > mention django_storages but you'll be hard pressed if you want to store your > static and user media in different buckets. It's one of the reasons I added > options to the constructor for the s3boto backend (I'm the current > maintainer) in django_storages and added a STATIC_STORAGE_KWARGS in my > branch of staticfiles on bitbucket. Not sure it was the best solution, but > it works. > > I would like to stress that using the same storage backend for static files > and user generated files is considered bad practice, which is also why I > haven't applied your changes in the staticfiles app. It was a distinct > design decission to have both kinds of files in different locations and to > provide the STATICFILES_STORAGE next to the DEFAUL_STORAGE setting for > further extension. I can imagine situations where you would want to store uploaded data and static files in S3 (but in different buckets or directories) to take advantage of the Cloudfront CDN. That just one example but I'm sure there are others such as storing static media in a normal directory and uploaded media on a shared NFS mount (some people do that). I suppose subclassing the backend simply to provide different options would be doable but didn't seem as nice at I need to support it in code rather than just changing some settings. That said, the StaticFilesStorage seems to do exactly what you described so if it's discouraged for some reason (which I'm still not sure I understand) then I'll respect your API. > I can't comment on the backends in django-storages much since I'm not very > familiar with the code, but I assume that it's possible to subclass those > storage backends to change the options, as needed. An extended example on > djangosnippets.org or in the django-storages docs would cetainly be useful > to have of course. If you have any suggestions regarding the staticfiles > docs with regard to using other storage backends, I'd appreciate your help. > For the S3BotoBackend at least, you would just need to subclass and override the __init__() method to call super() with the options you need, which would mostly likely be environment specific and set in the settings.py anyway. -- Ian http://www.ianlewis.org/ -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-develop
Re: Gentle Proposal: add 'render' shortcut in 1.3
On 10/21/2010 01:39 AM, Mikhail Korobov wrote: 1. Developer writes a view and want to reuse it (e.g. change the context). My assumptions was: a) Class based views are now the recommended way to write reusable views This is where our views differ. I have to admit that I didn't follow closely the process of designing class-based generic views but I never had a feeling that the class-based approach was now somehow recommended way to create views in general. If it's the case it would be the most significant change in overall Django design since introducing meta-class based models (and a really bad change if you ask me). Can someone of core committers clarify this: is it now recommended to write all views as classes? b) The main benefit from TemplateResponse is the ability to reuse view responses. I made this assumption because of the example in #12815, the 'this pattern would be particularly valuable for customising the admin' statement and the original example in your proposal ( http://groups.google.com/group/django-developers/msg/d5df254f01800ee2 ). Yes this is the main benefit. The example with middleware from my previous email was misleading, sorry. Thanks for pointing out the implemented TemplateResponse. No, I haven't actual objections against it and just don't want to complicate the implementation. There was an issue with TemplateResponse approach for Ben Firshman ( http://groups.google.com/group/django-developers/msg/fc9e0f8810d3e784 ) and the ticket is in DDN so it is not as simple as just replace HttpResponse with TemplateResponse. I can't test it right now myself but from what I remember exceptions in the response middleware were always handled. And in the 1.2 cycle we've fixed it for request middleware too. So may be the problem doesn't even exist anymore. Can you point me to that ticket which is in DDN so I could test it? -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
