Re: Ticket #25236: Remove ifequal from the template language

On Fri, Aug 7, 2015 at 3:06 PM, Aymeric Augustin < aymeric.augus...@polytechnique.org> wrote: > > On 7 août 2015, at 05:43, Curtis Maloney > wrote: > > > > I'd probably go with updating the documentation to say they're legacy > > tags, you're better off using {% if %}

Re: Decoration of class based views

Sorry did read the commit code now and the new *method_decorator* seems to solve most of the problem On Thursday, August 6, 2015 at 11:21:36 AM UTC, Fabrizio Messina wrote: > > Hello I would like to ask why the class based views documentation seems so > much ugly. Some developers probably are

Re: #25227 Add utility method `get_updated_model()` to `ModelForm`

2015-08-07 16:51 GMT+02:00 Martin Owens : > Could we use something simple like 'update()' and 'commit()' to which save > would call both? Or `.apply()` and `.commit()` not to suggest that the form gets updated in any way. -- Patryk Zawadzki I solve problems. -- You

Re: #25227 Add utility method `get_updated_model()` to `ModelForm`

> Add utility method get_updated_model() to ModelForm > > I think the problem I have with the name here is that I often think of the Model as the class definition and not the instance object that the model makes. When I got passing around model classes like a mad django diva, I might get

Re: Ticket #25236: Remove ifequal from the template language

I think Tim's suggestion of releasing the tag as a separate library which can be included in builtins answers Karen's concerns about updating 3rd party templates. I admit that is a case I had not considered. Marc On 7 Aug 2015 15:31, "Tim Graham" wrote: > I put together a

Re: Ticket #25236: Remove ifequal from the template language

I put together a pull request to see how much code we are talking about: https://github.com/django/django/pull/5114 It's 275 lines of code (mostly tests). I don't mind the outcome of the decision either way, but as it's been 5 years since the release of 1.2 and the "smart if" tag, I'm not sure

Re: CSRF_FAILURE_VIEW should not be used when DEBUG is False

I guess we might have to wait for Luke to reply to explain the reasoning for the original decision. On Friday, August 7, 2015 at 8:47:23 AM UTC-4, Žan Anderle wrote: > > That's true. But it still seems a bit off, that all other 4xx will be > handled diffrently with DEBUG=False. Shouldn't the

Re: CSRF_FAILURE_VIEW should not be used when DEBUG is False

That's true. But it still seems a bit off, that all other 4xx will be handled diffrently with DEBUG=False. Shouldn't the default behavior for csrf failure be the same? So while it's not a bug, I still don't get it why I should update the view for CSRF failure, while I only need to create

Re: CSRF_FAILURE_VIEW should not be used when DEBUG is False

It doesn't seem to be a bug to me as there's nothing in the documentation that says the view should only be used when DEBUG=True. The default template also includes logic to vary the content based on DEBUG. On Saturday, August 1, 2015 at 11:28:57 AM UTC-4, Žan Anderle wrote: > > Hey everyone! >

Re: How to disable system check framework?

Could you elaborate on why disabling system checks entirely is better than selectively disabling checks that are problematic for you? Is it really never helpful? If there are more people clamoring for this feature, I think I'd be more open to it. SILENCED_SYSTEM_CHECKS = ['admin.E108',

Re: Django's model_to_dict(...) should return ALL fields, including hidden

As mentioned on the ticket, I think this discussion should first be about whether or not this function should be a public API. Could you please describe your use case? On Friday, August 7, 2015 at 8:01:41 AM UTC-4, Anton Danilchenko wrote: > > Hello Django users and developers! > > I found that

Django's model_to_dict(...) should return ALL fields, including hidden

Hello Django users and developers! I found that Django's function *model_to_dict()* is useful in some cases. For example, I can transform any Django ORM object to a Python's dict. But the problem that I found - that I can't grab all Model fields, because *model_to_dict()* return only fields

Re: Ticket #25236: Remove ifequal from the template language

Django 1.9 has the option to add templates tags to the builtins using the TEMPLATES setting, so it wouldn't be difficult to publish a third-party app with the legacy tags and document how to use it in legacy projects that have difficulty updating: OPTIONS={ 'builtins': ['ifequal.tags'], }

Re: Django Admin New Look

Just posted a comment regarding inline SVG here: https://code.djangoproject.com/ticket/20597#comment:12 If everyone is fine with Font Awesome - I'm going to create pull request in master. -- You received this message because you are subscribed to the Google Groups "Django developers

Re: How to disable system check framework?

Thanks for the snippet, Aymeric! I've found similar on Gist, but yours seems to be better. Thanks. Marcin On Wednesday, August 5, 2015 at 11:10:25 PM UTC+2, Aymeric Augustin wrote: > > Hi Marcin, > > Thanks for the clarification, that's helpful. > > The backwards compatibility wrapper looks

Re: How to disable system check framework?

On Thursday, August 6, 2015 at 5:36:09 PM UTC+2, Tim Graham wrote: > > Perhaps your monkeypatches should be moved to `AppConfig.ready()` methods > so they are applied before the system check framework is invoked? > I'll try that, thanks. To be honest I should remove monkeypatching, I don't

Re: Decoration of class based views

No my point is that the proposed solution: https://docs.djangoproject.com/en/1.8/topics/class-based-views/intro/#decorating-in-urlconf will couple logic inside the urlconf and the methodology itself tend to create hard to read code. Still I think it makes sense to choose to wrap the

Re: Ticket #25236: Remove ifequal from the template language

> On 7 août 2015, at 05:43, Curtis Maloney wrote: > > I'd probably go with updating the documentation to say they're legacy > tags, you're better off using {% if %} now, and warn they may be > removed in a later release. This is my inclination as well. Then we can