For discussion: JSON-aware views for error responses
Hello Django devs! I'm a long time Django user and nowadays work with sites where Django is mostly or only an API for the front end. I'm assuming this is not an exotic use case in 2022. One pain point I continue to come across over and over again is that Django by default only speaks text/html even if the request has application/json accept headers. This often results in situatios where the unassuming JS app burps a HUGE html response as a string to the user when something goes wrong. And yes, it's obviously not Djangos fault if the frontend developer is sloppy but I believe there's lots of things we could improve here. Some spesific things we could improve: - At least for 400, 500, and CSRF errors, send JSON (or empty response) back instead of HTML if the request is xhr or has JSON headers - Make it easy to override the JSON like we can do with HTML - Add good documentation to explain how this works and how it can be customized I'm interested in hearing comments about this, and opinions from the core devs if this would be something that could be built into Django. I haven't been active here for a looong time but this is a bit of a pet peeve of mine and I would be more than happy to implement this also. And to be clear, I understand we already have middleware APIs and various settings to handle this but my point is that I think handling this in Django core (even as an optional setting or middleware) would be most useful and right way to do this for the community. Sorry for the long post. Cheers, - VS -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/68ced6ec-342f-42f6-ba0b-1a51360fa119n%40googlegroups.com.
Re: Unittest on live data Was: Rolling back tests -- status and open issues
> Are other developers interested in "readonly unitests on live data", too? At our company we mostly test our Django apps with "live" data for various reasons. Our process is roughly following: 1. we make a sql-dump of the current production data (or part of it if it's REALLY big) and move it to the dev machine. (This is done via Fabric- or capistrano script.) 2. We create a new test db from the fresh "live" data. 3. We run the tests with a custom manage.py command that works around some problems in the current testrunner. This process works quite well for us and it's also mostly automated, so you just have to run one command on a dev machine (and in some cases type password or two) to make it all happen. I've been meaning to write a pony request relating to this but I haven't found a suitable description for it, yet. Basically, for our needs, it would be a great help if it would be possible to use raw sql dumps as fixtures for tests. - VS --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Proposal: django.forms.SafeForm - forms with built in CSRF protection
> I propose django.forms should include a SafeForm class, which is a > subclass of Form that includes built-in protection against CSRF. I > imagine the interface looking something like this: Why wouldn't the safe form class be the forms.Form class instead? We do XSS-protection by default already, so why don't we encourage CSRF- protection, too? If for some reason you wouldn't want CSRF-magic to your forms, we could have forms.UnsafeForm (or whatever). Of course, this would propably mean backwards incompatible change, but I think that this is something that we'd want in the long run. I'm not saying that we should push this further from 1.1 but that we should definitely make something like this (however it's implemented) as the default way in the long run. As a separate note, I'd also like some well documented low-level helpers to make protecting AJAX-calls easier. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Proposal: {% doctype %} and {% field %} tag for outputting form widgets as HTML or XHTML
> On the plane back from DjangoCon I implemented the {% doctype %} and
> {% field %} tags I proposed in that thread as custom template tags in
> an application called "django_html". You can grab the code from here
> and try it out:
> I'm pretty confident this is the right approach. What do people think?
I *love* the idea behind this.
I hate the fact that Django only outputs XHTML out of the box, even
though it should be the Web framework for perfectionists (with
deadlines and no time to write custom renderers only to get valid
HTML :)
About the {% doctype %} tag, should we then maintain a (potentially
long?) list of different doctypes and/or should there be a way to
define your own?
- VS
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: RFC: Django 1.0 roadmap and timeline
> So what's the point of hoping for September if it's not real? The point of deadlines are that people tend to try to make them come true. If there is something that I've learned as a project manager during all the years that I've worked as one, it's that deadlines are important. Its not as important *when* the deadline is, as long as there is one. If the proposed timeline is in the lines of "it would be great if we would have 1.0 by the end of this year", we'll still be having this same conversation about deadlines next year at this time :) - VS --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: RFC: Django 1.0 roadmap and timeline
> Jacob, honestly, where this date has come from? It can as easily be > August or October. You've outlined a good feature list and seem resolute > to stick to it. But unless all those lieutenants would plan their > features *in work hours*, you just can't know the date. Firstly, as Jacob said, the schedule is just a draft at this point. But I'm very much +1 on locking down spesific dates for any given milestone. It's vital to have firm schedule and dates for making it all happen in a relatively short period of time. As what would those dates exactly be, I couldn't care less. As long as they're not too far in the future, lets jazz on! :) And FWIW, I think the proposed roadmap is brilliant. Not too many features but still enough to make most of us very happy. Especially if we can get at least few of the maybes in. - VS --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: manage.py idea?
> Is this a common problem for people or just me? I don't run into it > with every app, but I do refactor my models often times and run into > this, and think it would be nice if there were a more automated way to > clean up those tables. I've bumped into this same problem several times. It would be nice that contenttypes-app would know how to clean up itself from time to time. - VS --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Localflavors: request for developers and triagers
I'm the author of the Finnish localflavor, #3847. > So could triagers please mark tickets with such strings as needing an > improved patch and could original developers of these files please > include any strings containing non-ASCII characters in as u"..." > strings, not traditional strings. I updated my patch to follow this practice. I'm not quite sure that the new patch is okay, but please add a comment to it if there's still something to change :) - VS --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Moving towards Django 1.0
It's good to see some push towards 1.0 > == Feedback == What about one-to-one relationships? They seem to have had a deprecated status for some time now. In addition to organizing the documentation, I'd also like to see some cleaning up and reorganization in the wiki. It also should be at least somewhat collaborative work, maybe some sprint weekend or similar. I think that the wiki is a great and valuable addition to the official docs, but it's getting very hard to navigate and find stuff as the content keeps growing. I'd like to help as much as I can, but I'm not very experienced Python-developer, so it would be nice to have some tips here on the list and maybe on the http://code.djangoproject.com/wiki/LittleEasyImprovements page, too :) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: UNICODE and newforms
> I see several ways how to solve this problem: > > 1) migrate django to unicode aka big bang approach +1 from me. I'm also working with Django with a language that has many "funky characters". I, too, am not very experienced with Python and unicode, but it's still a major pain sometimes. It would be _very_ nice to have unicode troughout the framework. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Newforms and hidden fields
I'm trying to convert my user registration forms to newforms and this
was my first glitch with them. My scenario is this:
user submits username + email, which are hashed and validation email is
sent to user. (Nothing is saved to db at this point.) User comes back
with the hash, which is then de-hashed to initial data for the second
registration form that asks for a password.
# Unbound form with dynamic initial data
f = MyForm(initial={'foo': 'initial value'})
Something like this would work well in my case. I could pass the
username and email as hidden fields with initial data, and then ask and
validate the password.
Apart from this little issue, newforms have been really fun to use.
- VS
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "Django
developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Customizable object tools
Replying to myself This would be great. But I think it would be better to name the templates __foo.html. It would make the customization of admin pages very easy and Django-like. D'oh. After looking the admin source code, this allready works! I wonder howcome it isn't documented? (Or is it?) Anyway, you can override the default admin template (at least for change_list.html and change_form.html) by putting your own template to /yourtemplates/admin// for app-wide override or to /yourtemplates/admin/appname/modelname/ for model-wide override, respectively. This is great. And I really think it should be better documented! :) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Customizable object tools
ao wrote: _change_list.html instead of original one. If it somehow did the same like with generic views where it looks for a _detail.html but loads a default detail.html if former does not exist. +1 from me. This would be great. But I think it would be better to name the templates __foo.html. It would make the customization of admin pages very easy and Django-like. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Branch Merges?
> - schemaEvolution > - the wiki-pages only talk about (at least 2 different) proposals. > does > that mean that one of the proposals has been implemented? which one? I would be very interested in testing this but for me the showstopper has been both the wiki-page (what's happening, or is anything?) and documentation (how do I use it?). The test files are not very easy to follow withouth documentation. I think that wiki-pages, in general, should have clear and up-to-date information of their status. SchemaEvolution-page is a complete mess, IMHO. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Suggestion: Better slugifying of scandinavic characters
> Completely removing umlauts etc. makes such a bad impression outside of > the US! It's like writing "Adran Hlty" instead od "Adrian Holovaty". Yes. I definitely agree. > Say. do people in Finland also usually rewrite into ASCII like this: Actually, in Finnish, no. I think (in URLs) that would be almost as bad as removing the umlauts alltogether. (But, AFAIK they do this in some european countries.) To give an example of the problem, consider this title for example: "Tämä on ääkkösiä sisältävä otsikko". Django slugifyes this into "tm-on-kksi-sisltv-otsikko". That's practically unreadable (in Finnish). A MUCH better version would be "tama-on-aakkosia-sisaltava-otsikko". I think that this problem applies in most european languages, too. Like, say, Swedish, German and French. Just my 0,02 e =) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
