Re: django-classy-tags and django-sekizai update

this weekend (PyHack event), and I'll try to set up a VM with restricted resources because I think my laptop might be too fast to reproduce the issues on "slow" travis-ci. Jonas On Tue, Aug 30, 2016 at 5:50 PM, Iacopo Spalletti <i.spalle...@nephila.it> wrote: > Il 30/08/2016 04:

django-classy-tags and django-sekizai update

Hi everyone, Over the weekend at PyCon Malaysia I've updated django-classy-tags and django-sekizai to 0.8.0 and 0.10.0 respectively. Both releases only changed Python/Django compatibility. Both now support: - Python 2.7, 3.3, 3.4 and 3.5 (dropped 2.6) - Django 1.3, 1.4, 1.5, 1.6, 1.7, 1.8,

Re: anyone working on adding Django 1.10 support?

People are reporting some changes in 1.10 "breaks everything" in sekizai/classytags/better-test etc, but it sounds like things are working for you? I haven't had time yet to investigate, so how urgent are fixes/updates to those dependencies for you? On Wednesday, August 3, 2016 at 3:33:42 AM

Re: Possibility to define default placeholder configuration

Hi Michal, Do you mean something like what is being discussed at https://github.com/divio/django-cms/pull/5006? Jonas On Wednesday, June 1, 2016 at 6:25:48 PM UTC+9, Michał Lechman wrote: > > Hi all, > > I would like to know if is there any reason why currently there is no > option to define

Re: view permission for contrib.admin

For what it's worth is love to see this in core too. my use case was for DjangoCon Europe where admins were allowed to see ticket info, but only "super admins" were allowed to change them as changes likely had an impact on payments etc too (read PayPal). The solution was that everyone had

Re: ORM refactoring, part 2

This thread caught my interest (because of potential implications for django-hvad). While the proposed changes break django-hvad, I've already written a simple patch for django-hvad, so this is a non-issue. (The problem was the cleanup of Query.where. master and 1.4 had lots of calls to

Re: A word about CSRF Protection and AJAX

Well writing a middleware in my app or decorating all views seems a little hacky/unclean to me too. In our specific use case, the django CMS the graceful degrading is done through the admin, our so called frontend editing is heavily javascript and AJAX base, without HTML forms. therefore we

Re: A word about CSRF Protection and AJAX

I beg to differ luke. Most of our AJAX POSTs we do are actually not a 'form'. Because we usually submit forms with 'normal' POST requests. What would be so terrible in just setting the cookie always? Jonas -- You received this message because you are subscribed to the Google Groups "Django

Re: Adding new buttons like delete and change in the admin changelist_view

It is indeed a wonderful and powerful thing, and luckily a thing that's already possible! Just edit the changelist_view template. For an example please have a look at https://github.com/joshourisman/django-tablib/blob/master/django_tablib/templates/tablib/change_list.html Jonas -- You

Re: Backends for i18n in a contrib app - #14974

Okay let's leave the database content problem besides here. Let's assume for a moment we use your idea and provide a couple of different backends to store your translations. How would third party applications ship default translations then? At the moment they use gettext pofiles and it works

Re: Backends for i18n in a contrib app - #14974

Okay I would like to jump in here quickly and give my two cents on this topic. A very important distinction that should be made is the difference between 'dynamic' and 'static' translations. I call translations 'static' when they're strings that are fix in the templates (eg the text on the

Re: Add Mod(%) Operator to If Tag

Alex Gaynor wrote: On Wed, Feb 10, 2010 at 12:10 PM, megaman821 wrote: Since Django 1.2 is not out yet I have been using the smart_if tag in all my projects, with one addition. Since I believe the new if tag is based on the smart_if tag code on Django Snippets, I want

Re: HTML 5

Suno Ano wrote: Sure, let me rephrase, any plans on template tags or filters to for example make use of the feature? Or any other HTML 5 goodness [0] for that matter? [0] http://diveintohtml5.org/detect.html I'd like to see using the new input types (eg for email form fields). Since

Re: HTML 5

Suno Ano wrote: I've looked at the users and devel mailing list but didn't find any information on HTML 5. I found http://github.com/rhec/django-html5 though. Can anybody tell me if there are any plans with regards to HTML 5 in Django and if so, what are they? Things like the feature [0] would

IndexError on debug page

Hi django-developers If you have DEBUG on and an error occurs, you might get an IndexError if you updated your code but the page still uses old code: File "/home1/ojiich/lib/python2.5/site-packages/django/views/debug.py", line 186, in _get_lines_from_file context_line =

Custom 404's

Hi django-developers! I have two things which bug me about custom 404's. First: Why isn't there a setting to define a custom 404 template? In Python one of the principles is "explicit is better than implicit", a file put in a directory looks rather implicit to me, a setting defining the name

Re: 1.2 Feature Suggestion

Oh... Well than consider this a 1.X suggestion. I've tried Rosetta however it just doesn't seem to work Also I don't really like to use 3rd Party apps for what I'd consider core functionality. I mean django boasts with having excellent i18n capabilities, but when it comes to actually

1.2 Feature Suggestion

How about making i18n strings translatable from the django admin site? I like how the whole i18n thingy is built from a template perspective, however getting the stuff actually translated (all those django-admin.py commands ...) is a pain and confusing. So why not integrate this into the

Re: Suggestion: Better way to extend user table

Rob Hudson wrote: > Take a look at ticket 3011: > http://code.djangoproject.com/ticket/3011 > > Thanks a lot! That's pretty much exactly what I want. In my opinion this should become a real feature and not just a patch. --~--~-~--~~~---~--~~ You received this

Re: Suggestion: Better way to extend user table

James Bennett wrote: > On Mon, Aug 17, 2009 at 11:35 AM, James Bennett wrote: > >>def __getattr(self, name): >>if hasattr(self.user, name): >>return getattr(self.user, name) >>else: >>return getattr(self.profile, name) >>

Re: Suggestion: Better way to extend user table

James Bennett wrote: > On Mon, Aug 17, 2009 at 10:57 AM, Jonas Obrist<ojiido...@gmail.com> wrote: > >> Thanks for your opinion on this, didn't know django had this feature >> once. But I just can't get it out of my head that there's gotta be a >> better soluti

Re: Suggestion: Better way to extend user table

? To me (at least in my code) my version seems pretty elegant... And unless I find a better solution I'll continue using it for my own projects. Jonas Jacob Kaplan-Moss wrote: > Hi Jonas -- > > On Mon, Aug 17, 2009 at 7:43 AM, Jonas Obrist<ojiido...@gmail.com> wrote: > >&g

DB Fields: reserved_names

I tried to add support for an opposite of 'choices' to DB Fields (namely CharField) but failed horribly. I still think that would be a nice feature so I thought I'd bring this to this group. Maybe someone can implement this. What I had in mind was an option reserved_names (or however you want

Re: HTTP Errors

It probably wouldn't be impossible to do it yourself and I'm well aware of the HttpResponseForbidden, but to me it doesn't makes sense that one error is considered an exception in django and the other ones responses. I'd like to see a unified way to handle this in Django and not just in my

HTTP Errors

I don't quite understand why I can raise a Http404 but not for example a Http403. I think one should be able to either raise all Http error codes (4xx, 5xx) or none. And I'd prefer being able to raise them as Exceptions --~--~-~--~~~---~--~~ You received this

OneToManyField?

In the documentation I see that there are Many-To-One Fields, Many-To-Many Fields and One-To-One Fields. What about a One-To-Many Field? You might now say that this is completely pointless since a Many-To-One Field reversed is basically what I want. But I'd say that in some cases it makes