Re: DJANGO_SETTINGS_FILE

Thanks friends, of course Daniele for the backup, and also James for the advice of course now that my first emotional reaction is over - thanks for your tolerance. Thanks for reading pretty much everything I have on this subject, looking forward to read feedback from all django-dev contributors

Re: DJANGO_SETTINGS_FILE

tl;dr I'm not debating deployment here: my automated deployments are fine the way it is today: I love linux and env vars, shells and subshells and so on. I'm /reporting/ that users have been fighting the lack for DJANGO_SETTINGS_FILE for as long as I can remember. In many case, they loose the

Re: DJANGO_SETTINGS_FILE

Tobias, Adam, I have "imagined" you this dialogue where you're helping people deploy an open source citizen lobbying tool in Django in an NGO was not to make you look bad of course, the intention was rather the inverse of that. This situation, and exact dialogue, I have actually had, see the

Re: DJANGO_SETTINGS_FILE

PM, "James Bennett" <ubernost...@gmail.com> a écrit : > On Thu, Apr 6, 2017 at 5:22 PM, James Pic <j...@yourlabs.org> wrote: > >> Do I need this to deploy my projects ? No of course, because I use the >> prettiest way hhihihi ;) I'm more than happ

Re: assertRaises vs. assertRaisesMessage

Without diving into implementation details, I recon I've been taught the same as Shai. An exception type should have only one purpose, thus testing the type /should/ be sufficient imho. That said, if you want to TDD the message, you're going to code a test for it, is there really another way ? ;)

Re: DJANGO_SETTINGS_FILE

There are indeed a nice handful of apps out there that help doing this in different manners. While we're at it, my own way is to make every project a python package with a setup.py. So the settings can always be imported. Then I let docker swarm or kubernetes handle environment variables which are

DJANGO_SETTINGS_FILE

Hi all! Life with DJANGO_SETTINGS_MODULE has been great. However, it requires the settings to be an importable module. In most cases, this is a straight forward "simple" python script. Sometimes it looks like it could make sense to add an environment variable that could use a file that is not

Re: Django versioning and breaking changes policy

I think people are always going to run into such kind of issues until they decide to add django-master to their test matrix​, so that each dependency and project should always have the chance to be ready for the next version of Django "0day". But perhaps I'm missing something. Best James -- You

Re: Will asgi become a PEP like wsgi is ?

On Mon, Mar 13, 2017 at 12:58 PM, Etienne Robillard wrote: > > As far I know Django channels is a Django framework enforcing a specific > messaging protocol in mind. Honnestly I thought the messaging protocol was just msgpack. > I don't see how implementing ASGI could help

Re: Will asgi become a PEP like wsgi is ?

On Mon, Mar 13, 2017 at 12:26 PM, Etienne Robillard wrote: > ASGI is for building platform-oriented web applications in Django. Could you elaborate on this ? The only mention of Django I found in the spec linked by the OT is "Django Channels ships with a no-op consumer

Re: Will asgi become a PEP like wsgi is ?

I do not see myself using Django without Channels anymore, it's become a basic Django feature for me and I just love it. Despite my perhaps lack of knowledge about the protocol internals, such features seem like it would certainly benefit the Python community and anyway I'd say it's worth a try

Re: Database connection retry

It seems like we have 2 kind of issues: - code broke runserver, - network broke runserver. In the first case, runserver waits for a code reload event which is perfect ;) In the second case, runserver also waits for a code reload event, which is not very intuitive after fixing a network error.

Re: Database connection retry

It works on SyntaxErrors because updating the code triggers a reload, but if the check fails for something that's not related to code (db conn, redis conn...) then it's stuck and we have to manually interrupt runserver to start it again, unless we touch some code just to trigger the reload as you

Re: Decoupling forms from models

Sure, this probably involves allowing Form instance definition by composition with a new object (ie. FormConfiguration, ModelFormConfiguration ...) rather than by subclassing Form or ModelForm. I'll make a complete writeup about it ala Diderot then haha -- You received this message because you

Re: Database connection retry

Thanks for sharing some of your insight Aymeric, if I'm not mistaken then the auto-reload feature/case invalidates Shai's suggestion: would you recommend that the runserver process exits with non-zero when a check fails rather than being stuck waiting for another code change to trigger a reload,

Re: Feature idea: forms signals

Seems similar to this discussion: https://groups.google.com/forum/#!searchin/django-developers/forms%7Csort:relevance/django-developers/zG-JvS_opi4/wS-4PBfPBwAJ Yes, signal/slot is a pattern that allows quick and easy decoupling of components that have to work on the same payload, and I've been

Re: Database connection retry

until manage check; do sleep 1; done; manage runserver would work for me then, thanks Shai ! However, I'm still a bit puzzled by having a process that's just stuck when checks fail (if I understand correctly) is there any particular reason why it is this way ? If not, perhaps a retry or exit

Re: Database connection retry

Thanks for your feedback, the use case i was talking about is not quite valid anymore, since docker-stack and docker-compose v3 ​do handle dependencies. However, perhaps runserver could just exit if checks don't pass, which makes sense I think, allowing the optional use of a shell loop. I'd

Re: Database connection retry

Sometimes it's not started because some modern orchestration tools such as ansible-container and docker-compose (perhaps more) start everything at once, and django might be faster than the db, or I have to fix something with the db orchestration tool. I noted we might have the same issue with

Database connection retry

Hi all, It seems like runserver won't retry to connect to the database after a failing connection. Once the db server is up, it looks like I have to restart runserver manually. If this is correct, may I suggest that we make runserver retry connecting to the database if it fails ? Thanks --

Re: Model translation and meta options

On Wed, Feb 15, 2017 at 12:21 AM, Adam Johnson wrote: > Sorry for the terrible pun here, but I'd like to suggest the > meta-feature... allowing 3rd party apps to add their own options to Meta > classes. If there was a sensible API for this (or if Django just copied all >

Re: Presenting DCP, a compatibility layer for Django (feedback welcome)

If you've been maintaining several django apps for several versions of Django (ie. stable, oldstable, lts) then it's pretty easy to imagine how useful this can be. The deprecation policy removes the need of a compatibility layer for code that should support only one version of Django, but does not

Re: Decoupling forms from models

There is a history of problems related to the coupling between forms and models. For example, when a user suggested to pass a field instance to the model field to make it default [0], or when I suggested to improve formfield [1]: it was rejected because it would increase the coupling between forms

Decoupling forms from models

Hi all, Currently, the model fields define which form fields should be used for them by default. That's why we have to specify form stuff such as "blank" when declaring our model fields, and pretty much everybody would like to see a fix appear. Would it be possible to add a new option for users

Re: #26369: default formfield callback override

Thanks for your reply Adam ! To make it general purpose, perhaps we could make such a patch in Django and replace should_fixup by a signal ? -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe

Re: #26369: default formfield callback override

Thanks a lot for your time and quick answer Adam ! The ModelFormMetaclass usage you suggest is not supported by Django at this point. Suggesting that doing it is easy and supported seems incorrect in my experience, starting with the fact that there is no documentation. There are a lot of problems

Re: #26369: default formfield callback override

Absolutely ! If we don't want to monkey patch, we can use the other step: 4. get control on the flatpage form in the admin: https://gist.github.com/Kub-AT/3676137 Then, there's the fatpages use case. Fatpage is an imaginary fork of flatpages that adds create and edit views. In this case, we also

Re: #26369: default formfield callback override

Thanks for your suggestion Adam ! However, I have a feeling that to apply that technique on the flatpages use case we'd also have to: 4. Monkey patch django.contrib.models.FlatPage.content, 5. Override and deal with flatpages migrations from now on. The proposal removes the cost of steps 1.,

#26369: default formfield callback override

Hi all, I'm looking for a way to override the default form field widget for some fields of some model classes, at the project level. Currently, we have to override all the model classes for that. That's considerable as a hack, because we don't exactly want to "override the default in every form

Re: Provide a simpler way to default runserver IP/port to 0.0.0.0:8000

I recon i use a single settings module that feeds from env vars for any project i touch myself, but I suggested adding a setting because that would leave the choice up to the user like it's currently the case in django projects (some people still rely on local_settings import or use several

Re: Provide a simpler way to default runserver IP/port to 0.0.0.0:8000

Perhaps we could override this default with a setting ? -- 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

Re: Autocomplete in Django 1.11: Widget in Forms Library?

On Tue, Oct 11, 2016 at 2:20 PM, Johannes Hoppe wrote: > > At the current point I don't see how we could add a more generic widget to > Django outside of the admin. This would require ether a manual registration > of models as autocomplete light does it, or another

Re: Form.Media: render inline css/js

Nice one Matthias ! We might have something similar, in dal, discussion is undergoing: https://github.com/yourlabs/django-autocomplete-light/issues/756#issuecomment-252368089 Currently ddf also renders json in a script tag in the middle of the form, i think I might take the same direction as you

Re: Built-in router link generator in Django

True, this is a feature that's been invented a countless number of times. Perhaps one implementation could be supported by the organization ? -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe

Re: Form.Media: render inline css/js

Thanks for the heads up, a similar ticket has been closed as wontfix, because it isn't compatible with CSP: https://code.djangoproject.com/ticket/13978 While I'm all against inline scripts, I have a use case which seems be legitimate:

Re: Extend support for long surnames in Django Auth

Indeed first and last name dont make sense en various culture. In the Memopol project for exampe where wé have a table of European Parliament representative we have all sorts of names including (The Earl Of) name suffix which is part of the reasons our first / last name system was completely

Translatable Site.name

Hi all, Are there any plans to make Site.name translatable ? Would that be something we want to offer as a feature ? Thanks -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group

Re: Rewriting admin internals

On Thu, May 26, 2016 at 4:37 PM, Tim Graham wrote: > I'm skeptical of moving anything JavaScript related from admin into core as > this makes a stronger endorsement of and coupling to jQuery. Makes sense, would there be any intermediary solution at least ? -- You received

Re: Rewriting admin internals

There are a lot of interresting things to do, perhaps we could extract code from the admin into the core ? An example of this is the django-addanother app, which replicates the pattern used by the admin add another widget in an app for usage outside the admin. Would moving that kind of things

Re: Testing pre-release Django

I've found testing your own projects on django master to be tremendously useful. Then, I don't have any surprise when I test on django alpha, everything passes and I have nothing to do. Not to mention the tremendous amount of things I learn on the way, at a slower, more regular pace. Compare this

Re: Rewriting admin internals

Shouldn't the forms refactor happen first ? -- 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

Re: Testing pre-release Django

Please test your projects against django master too. On May 21, 2016 1:31 AM, "Ed Morley" wrote: > Another idea might be to encourage more packages to test on Travis against > Django master (with that sub-job marked as allowed to fail, so it doesn't > fail the whole run) -

Re: Decoupling Permission-Check from Calling the View

Hi all, I agree with Thomas here, we shouldn't give any detail to the user blocked because of permission configuration. We should however log that somewhere like django-rules-light for the admin. BTW This proposal looks great, keep up the good work B) James -- You received this message

Re: Vendoring multipledispatch

Adding dependencies would definitely be a huge step forward. I think Django doesn't have them because pip wasn't as awesome as it is today back in the early days, but nowadays it would definitely make sense. That would mean a bit more work for distribution package maintainers but if we can start

Re: Override the default form field for a model field

On Sat, Apr 2, 2016 at 10:44 AM, Florian Apolloner wrote: > Yeah, I am also mostly worried about this. formfield for me is a quick > shortcut, if you want to customize it, do it at the form level imo. Does this mean we can close #26369 ? -- You received this message

Re: [GSoC 2016] Please Critique (Condition API - Related to Auth)

Hi Connor, Overall I find it pretty cool that work on this has been started. There are a few questions I'd like to ask on this proposal. In this example: class ReadingDelete(UserPassesTestMixin, DeleteView): model = Reading def test_func(self): user =

Re: Override the default form field for a model field

Yes, overriding the model field to change the definition of formfield() works. It is indeed possible to define two model field classes which have different formfield() methods, for example: ManyToManyCheckboxField() ForeignKeyRadioField() Should Django provide such fields ? formfield_callback

Re: Bringing some popular must have django tools/packages under django org umbrella

On Wed, Mar 16, 2016 at 3:22 PM, Matías Iturburu wrote: > Even if I submit a patch I wouldn't be able to: > - Merge it into mainline. > - Upload the patched version to pypi. > > So it's a no-starter, > I can't rely on my fork, not for production, as I > should guarantee that

Re: Feedback on Django Channels

Perhaps it is a bit early for this but Is there anywhere origin is checked against ALLOWED_HOSTS ? Middleware support would be nice to but I guess you'll come to that when implementing user authentication. Keep up the great work ! -- You received this message because you are subscribed to the

Re: Override the default form field for a model field

If we prefer to remove form related stuff from models, then we should be able to register new default model forms: models.py: class YourModel(models.Model): your_field = models.BooleanField() forms.py: class YourModelDefaultForm(django.?.ModelFormConfiguration): class Meta:

Re: Override the default form field for a model field

On Thu, Mar 17, 2016 at 2:17 PM, Tim Graham wrote: > It seems useful, but I'm not sure if it increases the coupling between model > and forms in an undesirable way? The coupling is already there because model fields sit right in-between the db and form fields, so I don't

Re: Bringing some popular must have django tools/packages under django org umbrella

FTR, there's also Djangonauts which have been there for a while: https://github.com/djangonauts Sorry, I tried not to look uncivil - and yet I fail to see where I was, but definitely re-reading and thinking about it (I'm not an english native speaker). Please anyone feel free to PM me and point

Re: Bringing some popular must have django tools/packages under django org umbrella

What do you mean stuck? Aren't you supposed to port the packages and submit a patch in that case? How are you stuck ? I know the first portings are hard but once you've ported a dozen it becomes piece of cake so don't be afraid of trying ! And please contribute to the apps !! I know some people

Re: Bringing some popular must have django tools/packages under django org umbrella

Sorry for to quoting:/ -- 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

Re: Documentation for deployment on OpenShift Origin

I'd like to illustrate why I think having official documentation about deployment on PaaS would be great. What I mean by "there is confusion", is that IMHO on a PaaS SECRET_KEY should be managed by settings.py in an automatically created file in a private and persistent directory. For example:

Re: Documentation for deployment on OpenShift Origin

Pretty nice docs they have nowadays I recon ! Perhaps we don't need documentation for all open source PaaS out there (ie. DEIS, the open source heroku-ish PaaS for CoreOs). Having at least one could help though. The only documentation about deploying django apps is in their blog and it's not

Re: Documentation for deployment on OpenShift Origin

Perhaps, should we also start moving mod_python / uwsgi docs upstream ? -- 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

Documentation for deployment on OpenShift Origin

Hi, OpenShift Origin is an Open Source PaaS system based on cool stuff like kubernetes, docker, ansible, golang ... developed mostly by RedHat. It's probably comparable to Heroku, but more flexible and completely Open Source (thanks RedHat !!). I use OpenShift every day, including for a few open

Re: thinking about the admin's scope and its description in the docs

On Tue, Mar 15, 2016 at 1:59 AM, Ramez Ashraf wrote: > > 1. Inlines (FormView is like a teenager playing in the park next to Spartan > Hero) There are inlinemodelformsets you can use outside the admin. > 2. Entry Log change message django-activity-stream or even

Re: Django startproject template enhancement proposal

That sounds pretty fair, particularly since the new default settings provide a great ootb experience. Thanks for your feedback, keep up the great work ! -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To

Django startproject template enhancement proposal

Hi all, There's a pattern I like to use in my projects which I'd like to suggest for django startproject. It looks like: project_name/ setup.py src/ myapp1/ myapp2/ project_name/ settings.py urls.py manage.py wsgi.py My settings.py here uses environment

Re: Override the default form field for a model field

I just meant that currently, if a user wants to make Select2 the default widget for a model field, it is necessary to subclass the modelfield class and override the model field's formfield() method just to change the default widget it uses, sorry if it wasn't clear ! -- You received this message

Re: Override the default form field for a model field

On Wed, Mar 9, 2016 at 3:09 PM, Johannes Hoppe wrote: > We'll you can change the `default` form Field using > `django.db.models.Field.formfield`. Do you mean that, for example, an app like django-select2 could provide the following model fields ? -

Re: Override the default form field for a model field

Hi ! Currently, by default, django's ModelForm uses form fields which are known to be compatible for the modelfield. By "compatible", I mean that it works when the ModelForm calls: - ModelField.value_from_object() to get the initial formfield value for the model's field, via model_to_dict:

Re: Override the default form field for a model field

Thanks Tim. Something like that would work, perhaps the first step would be to make modelfield.formfield a bit more configurable ? Currently, the default form field class for a model field is hardcoded in the model field's formfield() method, ie:

Override the default form field for a model field

Hi all, Currently, the model field defines the default form field that's used by the modelform metaclass. It would be nice if an external app could overwrite this. For example, a user installs an app which provides a more elaborated relation select field. They configure the app to be able

Re: Logged out sessions are resurrected by concurrent requests (ticket 21608)

Just click "Details" and then "Console output". You'll find this: + flake8 ./django/contrib/sessions/backends/db.py:91:30: E901 SyntaxError: invalid syntax ERROR: /home/jenkins/workspace/isort/django/contrib/sessions/backends/db.py Imports are incorrectly sorted. ---

Re: Extending ModelForm.save_m2m

Sure, my bad, this is the example with form_business, a GFK, before / after: https://gist.github.com/jpic/c6a16723db62f779848f If we make it to encapsulate value_from_object / save_form_data elsewhere than in the model field then it will allow form fields and forms used in the admin to do more.

Re: Extending ModelForm.save_m2m

Thanks for the advice, I started trying moving form-related stuff from FieldBase into a new ModelFormFieldBase class, and it turns out that there's a lot more we could, or should, move than just value_from_object and save_form_data. Why not move out everything that couples the form field and the

Re: Extending ModelForm.save_m2m

Hi all, My understanding of the design issue I'm facing was too approximative at the time I opened this topic, sorry about that. The way I understand it now, is that we have only 2 moving parts but 3 features: - input validation in the form field, - business logic in the model field, - problem:

Extending ModelForm.save_m2m

Hi all, Many apps provide new related managers to extend your django models with. For example, django-tagulous provides a TagField which abstracts an M2M relation with the Tag model, django-gm2m provides a GM2MField which abstracts an relation, django-taggit provides a TaggableManager which

Re: Deprecate choices argument in Select.render

Felt free, thanks for answering. -- 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

Deprecate choices argument in Select.render

Hi all, In Select widgets, as well as many other (including MultipleHiddenInput, where it's not used) rendering methods all have a choices=() kwarg and use a chain(self.choices, choices) when rendering. Maybe I'm missing something, but it seems like this has just been sitting there since 2006

Generic M2M

Hi all, Generic Foreign Keys is pretty useful, do you think Django could provide a model with 2 GFKs and Generic Many-to-Many fields ? There is a little old implementation in an app that has been out there for a while so it's pretty old: https://github.com/coleifer/django-generic-m2m/ We could

Re: Admin widget to display user_permissions in tabular format

Awesome, we can drop support on that one: https://github.com/yourlabs/django-permissions-widget Keep up the great work !! -- 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

Re: Django 1.9 AppRegistryNotReady

In DAL we mostly moved autocomplete_light/__init__.py to autocomplete_light/shortcuts.py, and we're trying to make a fuss about it on internet so that users using google before opening issues find it :D It would be great if other libraries used the same renaming for the sake of consistencies

Re: Read-only overridden field appears twice in the admin

Done. Will debug the [French] out of this tomorrow at the sprint. Le 3 juin 2015 16:01, "Tim Graham" a écrit : > Yes, it looks like a legitimate bug. Please file a Trac ticket. > > On Wednesday, June 3, 2015 at 8:55:47 AM UTC-4, is_null wrote: >> >> Hi all, >> >> I've had

Read-only overridden field appears twice in the admin

Hi all, I've had this issue reported for the second time in django-autocomplete-light's tracker. For the first time on Jan 16th 2014 by a user whom I thought was a django core-dev so I didn't really bother following up on this - I beg your pardon for that. This has also be reported a few hours

Re: Suggestions on a form library

You should use something like bitbucket or github. Did you check existing form libraries like django floppy forms or django crispy forms ? I think this belongs to django-users as well. -- You received this message because you are subscribed to the Google Groups "Django developers

Re: Drop the TEMPLATE_DEBUG setting

Sometimes I had to enable DEBUG and disable TEMPLATE_DEBUG in order to get useful information about a crash. Am I the only one ? -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this

Re: Enable longer wait in StoppableWSGIServer.shutdown / hardcoded parameter

Russ I think it would work if the timeout was just increased. On Tue, Dec 10, 2013 at 12:36 AM, Shai Berger wrote: > > This would be a new feature, and I think it is a little late for one of those > for 1.6. In 1.7, the whole StoppableWSGIServer class is gone -- with Python >

Enable longer wait in StoppableWSGIServer.shutdown / hardcoded parameter

Hi all, I found that there was a hard coded 2 seconds limit in StoppableWSGIServer.shutdown: https://github.com/django/django/blob/1.6/django/test/testcases.py#L999 This causes problems on slow boxes ie. travis: https://travis-ci.org/yourlabs/django-autocomplete-light/jobs/15177543 Can we

Re: Working towards a simpler GCBV implementation?

I should state that I have no education and that I have the feeling that I understand GCBVs perfectly. But django-vanilla-views are not as usable because you cannot reuse isolated pieces of functionality like you can with mixins. Maybe this is a documentation problem ? Maybe the docs should

Re: AbstractUser to get more abstract

Why not just override the username class attribute in your subclass ? by None or even something which returns instance.email. In reality I have no idea, some of my users are using their email address as usernames and it's not a problem for django, so anything project-specific would sound a little

Re: New contributor and Git

GitHub has great http support now, which includes pushes. I think the documentation could mention https git urls everywhere: - let users who know about the benefits of ssh keys use them on their own, - let the others send their GitHub username/password at every push. -- You received this

Re: Should Django ignore leading/trailing spaces on login credentials

On Wed, Jul 3, 2013 at 7:25 PM, C. Kirby wrote: > I just ran into an issue where a user was copy/pasting username and password > from a text file into the login screen. For some reason the c/p process was > adding a trailing space to their credentials and they were failing

Re: Django Admin Revamp - Any updates?

There are *many* apps providing bootstrap templates for django.contrib.admin, here a few: - https://github.com/michaelhelmick/django-bootstrap-admin - https://github.com/gkuhn1/django-admin-templates-twitter-bootstrap - https://github.com/riccardo-forina/django-admin-bootstrapped -

Re: Performance problems due to incorrect many-many primary key on many tables

This might also work: https://github.com/simone/django-compositekey#customize-the-manytomany-intermediate-modeltable On Fri, Dec 7, 2012 at 10:51 AM, James Pic <james...@gmail.com> wrote: > I'm not sbure but I think you can make an external app that overrides > syncdb and creates op

Re: Performance problems due to incorrect many-many primary key on many tables

I'm not sbure but I think you can make an external app that overrides syncdb and creates optimised many to many tables before handing the job django's syncdb. If the tables exist, django won't create them. On Wed, Nov 28, 2012 at 9:56 PM, Anssi Kääriäinen wrote: > On 27

Re: testing tutorial feedback needed! (was: Testing documentation)

It's great! I just have a few questions: - would it be useful to mention that if the app lives in a separate (ie. open source) repo, it will need the repo to contain a test_project to run `./manage.py test theapp` in CI systems ? - would it be useful to add an example .travis.yml and some info

Re: I'd like to make a contribution to the wiki

I've set up the test_project of one of my apps - http://jpic.pythonanywhere.com/ (user/pass: test/test) it went pretty well. Great work ! One question thought, most of the time, free accounts disappear at some point, when the company grows. Are you committed to maintaining free accounts ? Thanks

Re: Improved ajax support idea

, Javier Guerra Giraldez <jav...@guerrag.com>wrote: > On Sun, Nov 25, 2012 at 12:04 PM, James Pic <james...@gmail.com> wrote: > > it would be great if we could make urls easier to reverse in Javascript. > > you shouldn't have to. > > good REST design means not

Re: Improved ajax support idea

I understand what you mean, I realized my point of view was too user-centric and not very conceptual. So, thanks for that and I'm still totally up to make or help making an external app in my next re-factor session. Here's a single point I'd like the list's attention: it would be great if we

Re: Improved ajax support idea

Hello everybody, Thank you for your feedback. And pretty soon I will tackle this problem in an external app - or consider joining the party if somebody else has started, in this case feel free to let me know. I can understand most of the points made here, expect just one, please bare with me.

Re: Trigger an event on add another

All Django admin would have to do is call: $(this).trigger('django.admin.another_added') or something like that. It really sounds like little work and would allow user defined callbacks to be executed. What do you think ? On Fri, Nov 9, 2012 at 12:29 PM, James Pic <james...@gmail.com>

Improved ajax support idea

Hi all, More projects use AJAX nowadays. Django could help them more. For example, FormView, could check if request.is_ajax_request(), and in that case return a JSON dict for example: { 'html': , 'messages': [], 'error_fields': [], } All generic views could do something like this.

Trigger an event on add another

Hi all, Is it possible to trigger an event on add-another ? Or is there a better solution to work around this problem ? https://github.com/yourlabs/django-autocomplete-light/blob/master/autocomplete_light/static/autocomplete_light/widget.js#L267 Thanks for answering Regards -- You received

ModelForm enforces its version of save_m2m

Hello everybody, Currently, Django ModelForm enforces it's local version of save_m2m: https://github.com/django/django/blob/38408f8007eae21b9f1cbbcc7f86d4b2042ff86a/django/forms/models.py#L76 As a result, users who want to overload save_m2m can not support commit=False:

Admin js: forward compatibility with jQuery

Hello everybody, I've fixed very little code in django admin (inlines.js, actions.js) which makes it forward compatible to jQuery 1.6. I'm willing to share it, i created a ticket https://code.djangoproject.com/ticket/17373 before i realized i was using a different version of jQuery. So my

Django test documentation example not respecting xUnit convention

Hello everybody, Sorry if this topic has already been brought, I asked about it on IRC but nobody answered. Being a old user of xUnit patterns in several languages, i just figured that there might be a mistake in django testing documentation example. The example is:

  1   2   >