Re: DJANGO_SETTINGS_FILE

[James Pic]

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 of
the world !

Best
James

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAC6Op18-nm5VEhUj_35-UxLu35TyjP6%3DHjS4pZNBJ-yS6Q%3DMPA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: DJANGO_SETTINGS_FILE

[James Pic]

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 fight and make something that's unusable
for an actual linux or django guru like you.

Have I really been the only witness of all kinds of horrors in
settings.py just because they wanted to have their deployment settings
parsed in it from another file path ?

I suggest we show people who do not abide by 12factor that they are welcome too.

I recommend we show people who do not have the technical background to
deal with env vars that we can think of them too, and not just about
ourselves hackers.

So, next time I have a Django deployment workshop with newbies, they
won't tell me: "You can't expect everybody to be a guru James".

Thanks for reading
Best
James

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAC6Op1-F0Yn8QM9x5qQjDtcXT-FRC%3DvN7v--YfcT8m6K6W1qdw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: DJANGO_SETTINGS_FILE

[James Pic]

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
source code if you don't believe me: there is a module called
memopol_settings and I have actually been bitten by this. Obviously I
forgot humility when I thought you would have said the same to the users as
you told me on the list - because I actually have - but it's true that I
was biased when I thought you would have done the same mistake as me, so,
sorry for making you look like you would have yourself :)

Anyway, people from over the world have been **fighting** this situation
rather than **fixing it upstream** for **ages**, see the demand:

https://djangopackages.org/grids/g/configuration/
https://code.djangoproject.com/wiki/SplitSettings

On one hand, I ear about all the efforts our community is doing to be
inclusive, and not being just elitist trolls (like me unfortunately but
working on it!!), on the other hand, we don't even provide a native and
simple way for user to put their environment specific configuration in a
file, despite the obvious demand (see links above, any NGO's workshop),
just because we, linux experts, are experienced enough to deal with it as
is.

"You can't expect everybody to be a guru like you James" is what people
have telling me over and over again, and what I'm working on (because my
name is also James). And that's exactly why I'm trying to understand where
they struggle and what's the most efficient way to fix it **upstream**,
because that's my philosophy, don't fight the controls, fix them.

Now, you say I can invent my own settings file system, or reuse any of the
existing system. While that is perfectly true, the problem with this, is
that I don't need any myself: I'm happy with env vars and a settings
module, because I deploy containers and set environment varibales at
container creation. At the risk of looking like a broken record (in
addition to everything I already look like, "le ridicule ne tue pas" :D):
it's not about me, it's not about you, it's about different users.

I'm ending up with a different implementation (that i don't need) in every
project I contribute to, because everyone creates their own, when after all
the need is the same: they just want a configuration file outside the
project with their environment specific thing. This is how I ended up with
a project in my hands, that requires writing an undocumented JSON
configuration file or something as warry as that. Currently I have to learn
each and every environment-specific settings file app there is out there
just in case somebody adds it to their project because of the lack of
DJANGO_SETTINGS_FILE.

After all, isn't the framework about proposing design decisions ?

Doesn't it make sense for a framework to at least provide projects built on
it with a way to pass a config file by path ?

And really, if the django project **should** be a python module so that the
settings should **always** be importable, then shouldn't startproject
create a setup.py ?

As you said, using django project shouldn't even **require** configuring
DJANGO_SETTINGS_MODULE even at all because it's hard coded in wsgi.py and
manage.py from the moment you run django-admin startproject. However,
DJANGO_SETTINGS_MODULE was never designed for deployment: environment
specific configuration.

So really, all we need users to do, is to call
`DJANGO_SETTINGS_FILE=/etc/theirconfig.py
./manage.py` (or `DJANGO_SETTINGS_FILE=/etc/memopol/production.py memopol`)
to keep environment specific, non-defaults, where it belongs: outside the
**public project**. Keep that in swarm, a json blob in etcd (ie.
kubernetes) or in a repository with ansible playbooks, chef recipes,
saltstack roles, for example it's your choice, but environment specific
variables have nothing to do in the public repository anyway.

About my joke on deployment debates, I recon I am in a currently mad love
story that drives me a bit crazy (in a good way) with gitlab-ci and docker
swarm, because it lets me treat server as cattle put a django project under
continuous deployment with like ~100 SLOCs of YAML and ~5 commands on a
server in NGOs that have no money to buy services such as Divio cloud or
else. I love it so much, it makes me euphoric, guilty as charged, I don't
feel like writing about it in a boring way where we can't indicate a joke
with " hihihihihi ;)". Because if I were going to write on this in a
boring way, I'd say perhaps making Django more comfortable to deploy for
non-technical users would not be good for business. But then again, I'm not
talking about commercial projects at all, rather, citizen lobbying tools
and the like, software for people who strive to change the world, people
without technical knowledge for example, but who have already changed how
politics work at some 

Re: DJANGO_SETTINGS_FILE

[James Pic]

I'm sorry you've seized the opportunity to use my effort to put a little
joy and humor in my message to push me on the slope, sorry that it's been
misinterpreted and that I just don't understand at all your technical
explanation. I guess there is always that risk.
Best
James

Le 7 avr. 2017 10:43 PM, "James Bennett"  a écrit :

> On Thu, Apr 6, 2017 at 5:22 PM, James Pic  wrote:
>
>> Do I need this to deploy my projects ? No of course, because I use the
>> prettiest way hhihihi ;) I'm more than happy to win a debate
>>
>
> Please don't do this. This does not make you look like someone who I could
> constructively engage with to try to figure out what problem is being
> reported and what a good solution would be.
>
>
>> And this is
>> how the drama begins, I can imagine them in front of Tobias.
>>
>
> Please also don't do this. You are perfectly well aware that people will
> give one type of explanation to a new user they're helping, and quite
> another to a mailing list of experienced developers discussing the merits
> of different approaches. And regardless of the context-insensitivity of
> what you're doing here, putting words in someone's mouth to try to make
> them look bad just makes you look bad.
>
> Meanwhile, Django has a way to avoid all the turmoil you've proposed in
> your reply -- run 'startproject', get package with settings file inside,
> run 'manage.py '. Several tools for deploying Django into
> production even make use of this, providing custom management commands
> which can be invoked to run/deploy/etc., and doing so requires no deep
> dives into Python imports, Python packages, or environment variables. Of
> course, a third-party package which develops its own independent
> configuration mechanism will need to teach all of its users how to make use
> of and deploy that configuration mechanism, but that's the responsibility a
> third-party project takes on when it invents its own method.
>
> --
> 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 post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/django-developers/CAL13Cg_JBcc6mYhH7un3LKgGFR22pZz%3D_
> kQyc0sB5dh4uq8g-g%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-developers/CAL13Cg_JBcc6mYhH7un3LKgGFR22pZz%3D_kQyc0sB5dh4uq8g-g%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAC6Op18F%2B3TM-P2NHb-qv4tXC0X9s1YJ045q5iK50HA45VULZA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: assertRaises vs. assertRaisesMessage

[James Pic]

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 ?
;)

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAC6Op19xUwQQKzutqmZW73cakbgaT6%2B2-0%3Dbn6MaZgS88PTGag%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: DJANGO_SETTINGS_FILE

[James Pic]

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 (surprise) environment-specific (the cherry on the
top being the entry point that points to manage.py).

I'm sure everybody here has a favorite way, which works, even if it's
not as pretty as my favourite way which is the prettiest in my opinion
of course ;) Let alone aesthetics,
DJANGO_SETTINGS_MODULE=production_settings
PYTHONPATH=/etc/yourapp:$PYTHONPATH is basically a lot more
error-prone than DJANGO_SETTINGS_FILE=/etc/yourapp/production.py, is
it even necessary to demonstrate this ? This somewhat reminds my
favorite talk this year, "Don't fight the controls", by Daniele
Procida.

Is there a problem to fix for any of us ? Probably not, we've been
deploying django for more than a decade with DJANGO_SETTINGS_MODULE.
We know are way in there, so nothing is going to change if our needs
don't change or if we don't take a step back to look at the bigger
picture.

Do I need this to deploy my projects ? No of course, because I use the
prettiest way hhihihi ;) I'm more than happy to win a debate
aesthetics of automated deployment any time with gitlab ci and docker
swarm or kubernetes of course, but actually that's not why that thread
was even about, sorry if I misguided you, this thread is neither about
you neither about me actually.

Do I need this in projects which I'm not the only one to deploy ? Well
now we're getting somewhere. You see, when someone makes settings.py
parse a json file, or read an environment file (yes, django-environ
actually has the feature to parse an environment file), it reminds of
E. W. Dijkstra's quote "The computing scientist’s main challenge is
not to get confused by the complexities of his own making".

Do you think this kind of situation would still have happened if
Django supported DJANGO_SETTINGS_FILE ? If so, would it at least be
less likely ? They wouldn't need to mess with the settings file that
we all share and that should not do anything more complicated than
reading the existing environment according to 12factor (and my taste
:)), they could just extend it and pass the path.

Do I ear about projects where they invent a new per-environment
configuration files ? Yeah, a lot, and you Adam, you actually have
never heard about it to the point where you call it "esoteric" ? How
is defining a configuration file esoteric ? What's esotheric here, is
PYTHONPATH=/etc/yourapp DJANGO_SETTINGS_MODULE=production (or should
it be production_settings ? doesn't matter, it'll smell a mile away
anyway). DJANGO_SETTINGS_FILE=/etc/yourapp/production.py is logical
and explicit. How me, kubernetes or docker swarm do
env-specific-file-less configuration, can be called esoteric, but it's
certainly not the other way around.

I'm sure many of you maintain open source django projects which are to
be installed by non technical people. I mean, I assume most of us are
either making big money in big corporations either dreaming of it, but
I also know most of us also dedicate a huge amount of time to
contribute to NGOs with Django, or just teach django for the pleasure
to share a passion. In any of this case, the project developer (us)
faces a bunch of people who are really willing to learn, python,
django, linux, bash, and so on, but have no experience. And this is
how the drama begins, I can imagine them in front of Tobias.

"How do I configure this project ?", they ask.

"Just **prepend** the configuration **directory** to PYTHONPATH, and
use the file name without the .py extension as
DJANGO_SETTINGS_MODULE", Adam says.

The user adds a file in /etc, called "memopol.py", to store their
settings. Then after they do what Adam told them, itsnotworking again.
"ModuleNotFoundError: No module named 'memopol.wsgi' 'memopol' is not
a package". I'm sure it won't take long before Tobias begins a
technical explanation (instead of working on the project itself):

"Well django couldn't import WSGI anymore because it was in
memopol/wsgi.py in the package, and python imported memopol from /etc
now that it's first in the PYTHONPATH".

"", (it doesn't matter, the user is lost, let's talk him into a
solution to cheer them up).

"So what you can do for example, is to prepend something unique to
your configuration file, such as _settings"

"Same error"

"What ??"

It won't take long before Tobias figures that this project also
depends on a module named memopol_settings.

And that's not even the worst case scenario.

Once you've been through this for a while, sharing your django
projects with non technical people, you start thinking "I won't forget
to ask django-dev if my friends can haz DJANGO_SETTINGS_FILE next
time". And here I am today, at their service, at your service, thanks
for reading.

-- 
You received this message 

DJANGO_SETTINGS_FILE

[James Pic]

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 importable as a python module, ie.:

DJANGO_SETTINGS_FILE=/etc/yourapp/production.py
DJANGO_SETTINGS_FILE=~/yourapp_production.py
DJANGO_SETTINGS_FILE=settings.py  # relative to pwd

Then, in this file, we could override the default project settings there
without having to put the new file in an importable module, ie. in
/etc/yourapp/production.py:

from yourapp.settings import *
DATABASES=...
CACHES=...
SECRET_KEY=...

I'm sure this has been discussed before but didn't find anything by
searching DJANGO_SETTINGS_FILE in the ML.

What's your opinion on this ? Is it time to upgrade this ?

Best,

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAC6Op19-0JeL8Jdcq70-pvwz%2Bi2hfKtopEvihca_rGfH1DrPww%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django versioning and breaking changes policy

[James Pic]

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 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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAC6Op1-baka6EfYqiDE9FO7bCvQjuVVMc0w3_r-Q72z768uEsA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Will asgi become a PEP like wsgi is ?

[James Pic]

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 to build more scalable apps
> without breaking compatibility with WSGI.
>

I thought ASGI could sit below WSGI without breaking compatibility.

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAC6Op190DqGD2Tw3rLVEWihEY9LxALuBZsQKYhmuJDjzFkpJ9A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Will asgi become a PEP like wsgi is ?

[James Pic]

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 attached by default; we recommend other implementations do
the same", so it doesn't look really coupled with Django overall:
http://channels.readthedocs.io/en/stable/asgi.html

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAC6Op1_H%2BRhz-zoC_x49tYMqSQksmjdNGZwXPdLRfX4aUG0RAQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Will asgi become a PEP like wsgi is ?

[James Pic]

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
just to see what the python-ideas list has to say.

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAC6Op1-p6O4pzUHcgZEE%2Bap8ZAdkQqeaC_bSi0%3DvF8GH%2BZBc4A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Database connection retry

[James Pic]

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.

So if we want to handle both case, we indeed need to detect if an error is
caused by code or networking, which is defined by CACHES, DATABASES and
CHANNEL_LAYERS.

Perhaps we could add a special attribute to the exception, so
DatabaseWrapper.get_new_connection()'s call of:

connection = Database.connect(**conn_params)

Would become something like:

try:
connection = Database.connect(**conn_params)
except Exception as e:
e.network_error = True
raise

Another way would be to inspect exc info or have a pre-defined list of
exceptions that are to be considered as network error, which involves
referencing to exceptions potentially defined by other packages such as
redis.

While that may seem a lot for runserver, I've restrained myself from
talking about what this could look like in production so far in the
discussion, but I feel like even production deployment could somehow
benefit from this at some point, so that might be worth the effort after
all.

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAC6Op1-xvvwDHpo-Qzc2ycQQ6q1H7NO5FFJbZQqzphOGfPrZvA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Database connection retry

[James Pic]

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
mention. My question is: is there anything we can do to automate this ?

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAC6Op1_bS5AF-ukvdPmqTjn-moxz05wSOgEktkYt9_nc10VLDQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Decoupling forms from models

[James Pic]

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 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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAC6Op18pYfRw5fb4FLt_uXeKOcCdTZsYpzbX16Mw%3D6nvOBAd8Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Database connection retry

[James Pic]

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, so that we could wrap it in an until loop in bash ?

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAC6Op190sX%3DnHepPOGikcFRAtvnNcEt8J-xMyDkeCjJPq-GZqQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feature idea: forms signals

[James Pic]

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 using
happily for at least a decade but I take your point as well.

About OVERLOADED_CLASSES, I don't think it's flexible enough, ie. to allow
an AppConfig to override a field of another app's form class, that was made
possible by David's initial proposal using signals.

If we're going to change this bit in Django, I'd like to recommend that we
try to cover a broader spectrum of use case, than just allowing a user not
to override a url to pass a different form.

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAC6Op18ifztiCqCm1Vr39%2BNGJJpCnu8a3gmYZ8sBMXyGtFZwSg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Database connection retry

[James Pic]

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 could improve the
developer experience

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAC6Op1-d8s5D-56PWQACEyfsv%2Bx1cS_R%2Bt9auuRVx6-e-S-Q0g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Database connection retry

[James Pic]

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 prefer
that, what do you think is better, exit or retry ?

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAC6Op18z%3D2nAfxEqiJPczWz5r%3DLBCEXjrcJuO2G3LK5M%2BQJVzA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Database connection retry

[James Pic]

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 redis+channels (if I've not
waited long enough before taking action instead of waiting for channels to
retry). It seems like something reasonable to improve the development
experience with Django while keeping up with the orchestration tools
because I've heard about other users making tools in python on top of
docker-compose just to add the orchestration that their Django project
needed (I swear) already two years ago.

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CALC3Kae-iWpWD3ZNFRu_GF9M0601bg8%2BpBGPR229%2BxgHrSfZ%2BQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Database connection retry

[James Pic]

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

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAC6Op19Q3nGUU1wCCsmdJbHhUvqEuaS-wNc9htAE1QXLQocsBw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Model translation and meta options

[James Pic]

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
> attributes defined in Meta onto _meta blindly), Django wouldn't have to
> add the translatable option without defining its behaviour.  Instead the
> third party apps could all define their own and use that.
>

I recon that was my initial thought too (this is also something we could
use for ModelForms BTW). While that would also work, I still think that
trying to make model data intl support as great as intl support everywhere
else in Django is a good idea - but I'm a non English native so I guess I
have strong feelings about this: without model intl I just can't use django
to communicate with my people. I still /believe/ "Django admin should at
least support translation of data, somehow, at some point". If we can have
a consensus on the requirement itself then it will be easier I think to
decide which first step to take to get there.

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAC6Op1-T3a7hcXoQBenQYd3kRMkGgwi7OTyxE1UAc59feAS_YA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[James Pic]

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 help maintaining code that should support several
versions of Django, which is a pretty cool challenge if you ask me :P

Thanks for doing this, looking forward to use it to make new django
versions easier to support in apps, keep up the great work B)

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CALC3Kafd-0UQxd156YCrt4gnrXsW%3DHoGPcwW-HQm3PLrEW%2BE1Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Decoupling forms from models

[James Pic]

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 and models:

On Saturday, April 2, 2016 at 10:44:44 AM UTC+2, Florian Apolloner wrote:
> On Thursday, March 17, 2016 at 2:17:40 PM UTC+1, Tim Graham wrote:
> > It seems useful, but I'm not sure if it increases the coupling between
model and forms in an undesirable way?
> 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.

So this leaves the one problem we actually want to see resolved: mandatory
coupling between forms and models. Which looks like the root cause, which
makes it different from the other threads which propose solutions to
problems created because of that, at least that's what I thought.

Here is a solution Tim already proposed [2]:

from django.db import models
models.CharField.register_formfield(MyCustomFormField)

As for the DEP, well I was going to just write one and submit it but then I
realized I could follow the advice in 1. Pre-Proposal of DEP0001:

> The DEP Author (see below for the formal definition of an Author) should
> first attempt to ascertain whether the idea is DEP-able. Posting to
> django-developers is the best way to go about this.
> Vetting an idea publicly before going as far as writing a DEP is meant to
> save the potential author time.


But I don't mind not writing it, it'll be easier for everybody if a native
speaker and more experienced django contributor would take care of it, if
it were to be accepted.

[1] https://code.djangoproject.com/ticket/22609
[1] https://groups.google.com/forum/#!topic/django-developers/TblESVmxGfw
[2]
https://groups.google.com/forum/#!topic/django-developers/zG-JvS_opi4/discussion

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CALC3KacJ_Rr1viUvz9dmc446nG-GZCQyzPoY2aAr6xRc25G0bw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Decoupling forms from models

[James Pic]

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 to specify the default
form field for a model field, **outside the models**, without breaking the
way it is currently done ?

If so, would it be DEP-able ?

Thanks, and of course: Merry XMas !

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CALC3Kae305TDiGmEXFv3KfxcTd056TiMOHBzjEt8OdOWFZtcXA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: #26369: default formfield callback override

[James Pic]

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 from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CALC3Kad0Y9ibX2Z9%2Bpj9mWCbc%2B63zEBqAGC8K1eD47mgMKe5Vg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: #26369: default formfield callback override

[James Pic]

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 out there with imaginary third party apps that
> you want to modify the internals of :)
>

I have to disagree here, it's perfectly supported to override the apps
views, forms and admins to change a widget: when it's done right it works.
It's just a lot of error-prone and manual work and I wish Django proposed a
way to reduce the cost of this.

In my experience, it works fine to enhance one app with the widget provided
by another. As demonstrated, it's already possible, but the cost of 6 steps
is something I'd like to reduce to one, DRY step.


> Often it's not hard to get third party apps to add some hook for extension
> (e.g. their own setting, or signal, ...) or to fork it yourself - easier
> than modifying Django core.
>

I don't understand why the community would be against reducing the cost of
using a form field or widget of an app to enhance another: given the number
of apps which provide just a form field or widget, I can hardly believe I'm
the only one to do this kind of things. I mean, are we formfield/widget app
maintainers so ahead time for maintaining such apps ?

I'm really sorry that I couldn't make it clear that we need a way to
"overriding the default form field generator ***mechanism***", and that
answers that were given to me are about just "overriding a form field",
similarly to the hundreds of StackOverflow answers and countless number of
blog posts I've published on this subject myself.

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CALC3KacjBh8XO09cStzAvRbSCdcuJn8Wd-CWZp26LuejMFMrZw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: #26369: default formfield callback override

[James Pic]

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 need the
following steps:

5. Subclass Fatpage views somewhere in our project so that it uses our forms

6. Override the create/edit urls to use our new views.

In the fatpages case, the proposal removes the cost of 1. 3. 4. 5. 6. and
cuts the cost of 2. by making it DRY-friendly.

About ModelFormMetaclass: are you suggesting to move the signal in
ModelFormMetaclass or do you have a lot more ambition ie. add new APIs ?

[0]
https://github.com/yourlabs/django-autocomplete-light/blob/v2/autocomplete_light/forms.py

[1] https://github.com/jpic/xmodelform/blob/master/README.rst

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CALC3KadzmHZ44gosFYJYmtKbH9Y0vWCXx%2BNwARvNOkEfnq_dcw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: #26369: default formfield callback override

[James Pic]

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., 3., 4. and 5 and cuts the cost
of step 2. replacing the change in multiple model files to a single change
at one place.

I definitely agree that a signal would be a lot better than a callback
setting ;)

=== ERRATA
There was an error in my previous email, this was actually the second
feature of the list:
- allows to override default form fields or form field options without
touching their code.
Should have been:
- allows to override external app model default form fields or form field
options without touching their code.

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CALC3Kad-ND9gBdn-zMTriM40b6YWyos34McCrHX1ncgLJ8UXjQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: #26369: default formfield callback override

[James Pic]

Wow, nice memory Tim !

Yes it's a problem I've been trying to find a solution for during the last
years. We've had a solution in DAL v2 by providing a custom model form
which would make relation fields to a model that has an autocomplete
registered use an autocomplete field by default. This solution was really
hard to maintain, and not even portable.

I couldn't reuse the system to just FlatPage use a wysiwyg field by
default, and had to go the usual, and I recon a bit messy road:
https://gist.github.com/Kub-AT/3676137 This is when I realized it had to be
part of the features that should be dropped from DAL v2 to v3, in favor of
a more generic and supported way.

The older discussion proposed another angle, in the spirit of #22609 [0],
that was not convincing because it would increase coupling between forms
and models because it requires to add even more form stuff in models,
because of the nature of the solution that was per-modelfield.

This is why this new proposal is based on a project-level callback setting
instead:

- does not require to add any additional form stuff to models.py,
- allows to override default form fields or form field options without
touching their code.

Note that there was also a suggestion to do something with fields_for_model
[1] to solve the problem, I don't think we're done studying this road on
the other thread so there might be more implementations to suggest here,
even though I feel like just being able to tweak defaults with a global
callback as proposed would just do the trick.

[0] https://code.djangoproject.com/ticket/22609
[1] https://github.com/django/django/blob/master/django/forms/models.py#L111

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CALC3Kad7%2BPrkJC0Cz2SsoB374%2BNxuJcN7z_2pANOQzpdBneBFg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

#26369: default formfield callback override

[James Pic]

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 class" but we want to "override the default".

The reason I need this at the project level is that really it's that unique
combination in INSTALLED_APPS that provides whatever widget I'd like to
override the default widget with, and how my project forms will look like.

For example, I'd like to have a RadioSelect for all relations to Foo model
and a django-redactor for all text fields named "html", my logic looks like:

if getattr(db_field, 'rel', None) and db_field.rel.to == Foo:
defaults['widget'] = forms.RadioSelect
if db_field.model == Bar and 'html' in db_field.name:
defaults['widget'] = redactor.RedactorWidget

A simple possibility is to add a setting which value would be a dotted path
to a callback, and basically change Field.formfield() so that it would use
this callback if it's defined. Here's an example patch: https://github.com/
django/django/pull/7723

Thanks for your feedback.

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CALC3Kacn1k01wW824r%3Dp5Dn87%3DfkfNLDxCZz_68x83HaBsjmeg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[James Pic]

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
settings modules such as settings.dev settings.staging etc). So i'm 0 on
settings vs. env vars myself.

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CALC3KachawFH_XoawXPjs54fd_r3yZ8AQGGB7MuZTJh_GxNs1A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[James Pic]

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 django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CALC3Kad9td5tjOsP2bDT-Awf8UAHtvRwW_3ijDxtmK_aPYaX2g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[James Pic]

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 approach that doesn't
> rely on Django cache.
>

In DAL v3 there is no need for model registration. Autocomplete widgets do
take a URL as argument though.

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CALC3Kaf8_E6eeHatLn2kn1KO%3Dp3Bwwm%3DO6d5Z0DE_81Qwb8Zww%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Form.Media: render inline css/js

[James Pic]

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 did there too:
https://github.com/yourlabs/django-dynamic-fields/blob/master/src/ddf/form.py#L28-L56

Ideally I'd have this provided by ddf.FormMixin, but I'm currently blocked
by a sort of bug-to-fix or feature-to-add issue:
https://code.djangoproject.com/ticket/27317 but I need to recenter the
discussion there, my initial description wasn't adequate as the suggestion
made in the comment isn't actually possible - or at least, is possible, but
doesn't do the job.

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CALC3Kaewwcg%2B10OPx4aXJrymgYOYiDtW8gO8k%2BQ41Q4KnjSdBw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Built-in router link generator in Django

[James Pic]

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 from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CALC3Kacd2DJxG%2BfcACre5z%2Bp%2BnO%3DmhuM6RRHRT4DOV4k%2BBd%2B%2BQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Form.Media: render inline css/js

[James Pic]

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:
https://github.com/yourlabs/django-autocomplete-light/pull/733/files#diff-469b501dd1f427cfe68aac4d27f28df3R84

Basically, we render a `json object
dump here` next to the widget and use that to configure the script
for that widget. IMHO, the ideal solution would be to be able to place this
script tag in `{{ form.media }}` rather than next to the HTML widget.

Am I missing any CSP concern here ?

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CALC3Kac1x61Ra45cnW5ScAj39BzCah5PLpwF7R6eVu7zirKP8g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Form.Media: render inline css/js

[James Pic]

Hello list \o/

Currently, we can attach scripts and css by declaring their urls in Media.
It then renders the script and link tags, allowing users to have that
outside the form tag in the template, ie. in the HTML head.

A good way to pass a widget's configuration from python to js is to pass
them as data- attributes, and make the js pick it up. This works fine for
simple key/value options, but not for more complex data structures ie.
complete JSON objects.

It would be great if we could also add generated css/js to ``{{ form.Media
}}``.

Thoughts ?

Thanks for your time

Best regards

James

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CALC3KackZYBsC6Y3iwTVMpsBmE1YzBrYU8L-xLpp6yvR94EuGg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Extend support for long surnames in Django Auth

[James Pic]

Thanks for your reply Aymeric. If I understand correctly the best way to
approach this, besides increasing the current limits - which I've had to do
myself a few times - is to create a separate app providing a custom model
with an ArrayField for name (sorting) and a migration script, and let time
tell if this is more useful than the current approach and wether it should
become default or not after a long-enough while ?

Again, thanks for your reply, every time I read messages from engineers
like you it makes me a better one myself and I'm sure it's the case for
most other persons. I understand it can sometimes be hard for you - and
other experienced core devs- to have to deal with us, so I really want to
show my appreciation and love and I think I can speak for everyone of us
when I say thank you for your contribution and your sharing and making
everyone of us better every time you take some time for us.

Keep up the great work

Best regards

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CALC3KaeNyMhAeG0_4L_j0KDg5hV_eAzucy42G1xiLMmfyHOtVQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Extend support for long surnames in Django Auth

[James Pic]

Aymeric, it doesn't matter if tens of milions of names fit into your
model, it only takes one to have a issue that's going to require the
project developers to invest time in it. So I'm a bit lost about
what's the most practical approach here.

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CALC3KaeTBeRU-S2Kk_639ikFP7Z7rxc7LAV17qcDfHM63ATh%3Dw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Extend support for long surnames in Django Auth

[James Pic]

On Sat, Jul 30, 2016 at 8:08 AM, Josh Smeaton  wrote:
>
> I think having a single name field is reasonable for the vast majority of
> cases, but it fails where projects really do need to identify two names for
> things like sorting or categorising.

I'd be willing to believe that a project requires storing names as an
array of words for sorting. I can see how that would be helpful to do
sorting. Even I have a full name of 5 words and I only use two of them
because it's my culture. In this situation how to convince someone
that it's not a waste of time to have to fill in several form fields,
when they are going to the usage name they want anyway which is
conceptualized rather as an array of words than a pair of words. Some
people won't even want their real name on some projects.

> I'd be willing to argue that if you did
> need to differentiate between parts of a full name then you could customise
> your User model to account for that. The issue is backward compatibility. We
> can't just use migrations to remove the last name field because that would
> break working code and potentially delete data. It'd break a lot more than
> simply increasing the size of existing labels.

Deporting the issue on the user project is an option, but I'd like to
suggest that we keep on trying to find a curative solution for this
issue which has been brought up on regularely. It should be possible
to make a migration to add and provision the full name column and make
first and last name column read-only if they exist - but not be
provided on new projects. Even then, the backward incompatibility will
be an easy fix, it's not like we were splitting data the other way,
that would be a lot more difficult and require esoteric code, again,
just like when we try to make people fit in two distinct inputs.

Free users from our culture, open django.contrib.auth to the world.

Rock'on

James B)

-- 
http://yourlabs.org

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CALC3Kaf4K6yh0y-K8F2TdhTPs2h7DKQw9%2BO1xN5538gr4u1hDA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Extend support for long surnames in Django Auth

[James Pic]

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 checkmated.

Nowadays I just go for a single and long name field and I would like to
suggest that django.contrib.auth takes this path too because the first name
and last name system isn't international and django is for building
websites on internet which is meant to be a communication tool connecting
Humans of the world, no matter if they have a first and last name or not.

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CALC3KafvSRCm8O8%3Dgnps9ogCoxc9Fz4%3DxdhXCM_MPDN9fv0Wmw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Translatable Site.name

[James Pic]

Thanks, I'm really looking for a way to use the models as this is for the
django CMS light project which makes dynamic multi site a central
requirement.

Perhaps we could make this model swappable ?

For now I'm just going to rely on the translatable site level yaml metadata
we already have in place for the page title and that'll fix the problem for
me.

Let me know if I can help

Enjoy DjangoCon ;)

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CALC3KadUKJhkWuQnLT-oFjHi9K_d%3D42MckUqgKbe9EeaRE_%2B7A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Translatable Site.name

[James Pic]

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 and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CALC3Kad1CEEpvz%2B4e6_qFO9x6Ya%2BjrFUsFN0TjA8KrVJACGQ2A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Rewriting admin internals

[James Pic]

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 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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CALC3Kae6aeOhpqvqGc-u8oy7M0rV2%3DSJ0jTpePXX2QNoYbg5WQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Rewriting admin internals

[James Pic]

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 from the admin
into django be the kind of issue you would like to solve incrementally
?

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 and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CALC3KadN%3DaTvA26t%3DAimt9aMEdnAFnxG9u9g_1QaJxu7idjR1g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Testing pre-release Django

[James Pic]

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 to before, when I was waiting
too long to test against the new/next version of django, had to face a
ton of different failures at the last minute, had to go and couchsurf
at another contributor's house to peer-hack at night after our
dayjobs. BUT that's how I made a best friend for life and that's
priceless hehe even though I wouldn't hold this as a technical
argument for not testing against master !

I guess each person will have a different opinion. Nowadays, I add
djangomaster to my test matrix on all projects, in "allowed failures",
and find out it's broken every once in a while, and just have 1
problem to fix at the time. It works very well for our community, so,
definitely worth trying and then deciding if that's how you want to
work or not.

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CALC3KafR7NLJryntqAo7LkiBL3YMfk_yjLgs%3D2%3D_%2BJsnSTd_QQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Rewriting admin internals

[James Pic]

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 django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CALC3KadqjUmxLeWT-jXT%3DGsCR2FcOZ1GOMVp-Q%3Djw4GjGdLu3w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Testing pre-release Django

[James Pic]

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) - so any incompatibilities become apparent earlier.
>
> eg:
>
> https://github.com/evansd/whitenoise/commit/c1a9f04cc90a7e48e536c651d9624660cee44073
>
> On Friday, 20 May 2016 14:32:53 UTC+1, Claude Paroz wrote:
>>
>> Hi,
>>
>> I have the general feeling that too few people are testing the new Django
>> major releases before the .0 release. The result being that many
>> regressions are often reported after the release, while those could have
>> been detected at alpha/beta/rc stages.
>>
>> I found myself in the situation where I really wanted to test my own
>> projects with a fresh new Django, but couldn't because some dependency was
>> not updated and was crashing the project.
>>
>> I wonder if it would help taking the most popular third-party
>> dependencies and help those projects testing with pre-release Django. As an
>> example, I added a Wiki page,
>> https://code.djangoproject.com/wiki/Version1.10ThirdPartySupport (to be
>> completed) as a mean to track Django 1.10 support progress in most popular
>> apps. The first step would be to at least add Django 1.10 (or even master)
>> as allowed_failures in Travis setups, so as 1.10 support is plainly
>> visible.
>>
>> Thoughts?
>>
>> Claude
>>
> --
> 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 post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/7129d115-482e-4564-bce4-45322da2a0f0%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CALC3Kae1O8NZCqb3%3DuXZmGpD6Z74tOB8PG3bXA50sr4LgUhhJA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Decoupling Permission-Check from Calling the View

[James Pic]

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 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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CALC3KadmNMb-KX%2BCtTkLYuj0cz%3DrsVqNNqeaFk59j_VO%3D9a7VA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Vendoring multipledispatch

[James Pic]

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 communicating with them about it then would there
be any reason not to do this move ?

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CALC3Kae1Mt5LzYRq0PQbQcEMKwvbK%2Begr4FuC6baB5NZZtSbtA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Override the default form field for a model field

[James Pic]

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 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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CALC3Kadk0RGFPi%3DVqhdsTxsMP52mGheYie_DuG%3Dw4LkH34YOdg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[James Pic]

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 = self.request.user
reading = self.get_object()
return reading in user.leader.club.readings.all()

Should we really fetch the object from all objects and then check it
against a "secure" queryset ? After all, there's absolutely no
security here between the "get_object()" call and the "reading in ..."
test. Wouldn't it be more efficient and safer to try to fetch the
object directly from a secure queryset ? ie: self.queryset =
user.leader.club.readings.all(); reading = self.get_object(). This
somehow relates to the Form Choices Filter sections of the proposal:

> running a Condition against every instance in a queryset can quickly become 
> very inefficient. For cases when it would be necessary, the mixin would 
> provide a callback to allow the developer to use whatever means they want to 
> more efficiently narrow down the queryset before the Conditions are run 
> against its instances. This may seem like redundant code, however the 
> purposes of the two different "narrowing" methods are not the same, one is 
> for efficiency, one is for security. Rough implementation:

The implementation is pretty rough indeed: it seems like the queryset
is narrowed only if method == 'GET'. Doesn't that mean that a
malicious user can validate a form with selected choice that was not
displayed in the initial rendering ?

IMHO this is the most challenging part of the subject this proposal is
about. Perhaps if Conditions could translate to combinations of Q
objects it would be easier to get the best of both worlds.


> As is probably fairly clear from the above code, a user attempting to access 
> the above view would have to have theiris_staff attribute set to True, 
> otherwise the view will (if the following behavior is not overridden) raise a 
> PermissionDeniederror with an appropriate message provided automatically by 
> conditions.RequestUserCondition.

What kind of messages would be appropriate to use here ? Wouldn't it
be tricky to find safe messages, that wouldn't help a malicious user
gain information about the security they are trying to circumvent ?
For me, this raises the same problem as with login forms: if an
attacker gets a "incorrect username or passord" message on a failed
login test then they don't learn if the username exist, whereas having
an "incorrect password" message on a failed login test does leak the
information that the username exists. That said, this kind of feature
would *definitely* by useful for logs.


> Since Clubs no longer have .leader (they now have .leaders), the if 
> statement's condition becomes nonsense, and due to Django templates' policy 
> of silent failure simply doesn't show the contents of the if statement, thus 
> not showing the links to the update and delete pages for that Reading.

If such a bug is found, then a the DoD of the bugfix should include a
regression test to ensure that leaders always see the edit/delete
links in the template response. Should Ahmad have duplicate logic in
templates like this in the first place ? I recon it's the same problem
everybody has to solve in their projects though: perhaps it would be
interresting to encapsulate this particular logic in a template filter
?

{% if reading.club.leader.user == request.user %}
Update
Delete
{% endif %}

Becomes:

{% if reading|can_edit:request.user %}
Update
Delete
{% endif %}

Or, with a context variable, like in the case of django.contrib.admin:
{% if has_change_permission %}. That said, I'm all for providing a
framework for Ahmad to have a convenient, consistent, secure and
forward-compatible way to encapsulate these permission checks.


> Combiners
> There would also of course be classes for combining multiple conditions into 
> one. The two "combiners" would beEveryCondition and AnyCondition.

Would it be nice to leverage & and | operators and perhaps have ~ for
negation like with Q objects ?


In this example:

class Book(models.Model):
class Meta:
conditions = {
'access': (IsInLibrary,),
'create': (IsAuthor, CanWrite),
'read': (CanRead, OwnsBook),
'update': (OwnsReadPen,),
'delete': (IsABadPerson,),
}

What is the difference between access and read ? Is 'access' here as
an example of non-default permission type that Django users could
implement, such as 'borrow', or would this be used by any feature
provided by the framework itself ?


> Eventually, the Conditions API could provide a mixin for views to take 
> Conditions that were originally designed to be run on objects and apply them 
> to the .c

Re: Override the default form field for a model field

[James Pic]

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 is documented here:

https://docs.djangoproject.com/ja/1.9/ref/forms/models/#modelform-factory

It is one of the many ways there are to create a model form which
provides a radio widget for a foreign key for example.

However, the modelform then has to be passed around / inherited from
everywhere then.

Issue #26369 is about overriding the default widget that is used by a
formfield. The user story is like: I change the default widget used
for a model field and this change is applied everywhere.

Does this help to see the difference between just overriding in a
subclass, and overriding the default used by ModelForm ?

[0] https://code.djangoproject.com/ticket/26369

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CALC3Kaf5%3D0qNNq%3DdXbJWVxYQOb42VjnwhJ5E5TWHJhLHBQBCww%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[James Pic]

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 the package it's, at least, as tested as mainline,
> which usually involves non-trivial infrastructure.

If I understand correctly, you need a patch, but you don't want to do
it, because you can't have it released right away.

Your work is to have a feature in a project, you want to use an app,
but you don't want to contribute to it. If I understand correctly, you
want volunteers to do the work for you so that you get your project
done and perhaps even get paid, and not give anything in return.

Good patches are quickly merged. If it has tests, and good code
coverage, and supports new versions of Python, I can tell you it's not
going to take long before your patch is merged in most cases.

Otherwise, yeah, just publish your fork on PyPi until it's merged
upstream. I don't see what's the problem here. We've had the case in
django-cities-light were a user implemented Region support, published
it in django-cities-reducedfat or something (lol), and then
contributed upstream, and then we released the contribution in
django-cities-light. What's the issue here ?

>>
>> 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 who only open issues and never submit a patch on
>> github, isn't that super annoying?
>
> Really? you go around asking users to do the work of maintainers?

I don't understand, what do you mean work ? Are you paying the
maintainers to maintain their projects ? Are you talking about
dual-licensed projects like django-suit where you payed an Enterprise
license for ?

Well what do you prefer, that maintainers shut down a project because
they don't have time or motivation to keep on, or do you prefer that
the project lives on with community support ?

If I understand your logic correctly, you should re-implement the
features you were using from an app in your own project to drop the
dependency on the app that you consider un-maintained. Either way, you
end up doing your job, but if you contribute then it's for everybody,
not just your project.

Seems like "Open Source" doesn't wrok the same in your world and in mine :)

Perhaps if you were maintaining Open Source apps you'd understand. I
don't know if you use any things like torrents, but do you know what
the "leecher" concept is like ? It's when a user downloads and then
doesn't share.

I don't think I have anything to add here, I'm sure more experienced
hackers will find better phrasings than me for this. I may sound
harsh, but really I'm not, I'm just trying to understand how your
logic works and so far it seems broken for me so I'd really like to
understand.

Also, about django-endless-pagination, I tried it once, but then
decided to go on with my own 5 sloc of JS implemantion of endless
pagination, using Django's normal pagination on the python side, so
I'd like to be convinced that it's really necessary in a project ! But
that I guess is another topic.

Best ;)

James

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CALC3KadeO16Z8Ao_8-jssS4NBkpg00ODcFaz%3DngQ7tzGPagyEg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Documentation for deployment on OpenShift Origin

[James Pic]

Hi all!

Perhaps the wiki is the best place for this kind of things?

Thanks for your feedback

Best

James
On Mar 16, 2016 12:59 AM, "James Pic"  wrote:

> 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:
>
>
> https://github.com/political-memory/political_memory/blob/master/memopol/settings.py#L38-L46
>
> You might be tempted to store it in an environment variable, but
> that's not safe because environment variables are dumped in deployment
> logs, like in their first example:
>
>
> https://github.com/openshift/django-ex/blob/master/project/settings.py#L24-L28
>
> In their other example (oh I found out they have two examples, more
> confusion for users !), they use some sort of system to store the
> secret key in a json file, that's a lot more complicated than it
> should:
>
>
> https://github.com/openshift/django-example/blob/master/wsgi/myproject/myproject/settings.py#L19-L28
>
> By more complicated, I mean that it doesn't even work because it uses
> a module that's not even in the repo anymore, so that won't even work.
>
> For DEBUG, there's one example where they do DEBUG =
> os.environ.get('DEBUG') == True, what happens if DEBUG is not set as
> an environment variable ?
>
> For static files, it's a bit more complicated on PaaS because you get
> one persistent directory, where you want MEDIA_ROOT to be, and one
> public directory, which is not served by the httpd. Their
> configuration doesn't even include MEDIA_ROOT support BTW, again
> there's only one way that works IMHO it's to symlink media from the
> persistent dir into the "public" dir, and have STATIC_ROOT in a subdir
> of the public dir - which again is not what they have.
>
> And I could go on like this for a while heheh
>
> Anyway, I'll try to contribute a new page about Django in the
> devcenter repo ( https://github.com/openshift/devcenter ) and hope
> they will want to merge it else I'll ask here again and as last resort
> post it on my blog which I can't even get on djangoplanet even though
> I asked several times in the past yearS.
>
> Best ;)
>

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CALC3KaeAmg%3Duh4K-qK5mua_38TU0fE7%3Dnuu1A2hN-EAWHqVYBA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feedback on Django Channels

[James Pic]

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 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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CALC3KacL7H3A-pW-zLQyDhx2c5ev3dd6syXHjqaV2F%2BigHXMdQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Override the default form field for a model field

[James Pic]

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:
help_texts = dict(your_field='your help text')

# Set it as default
django.?.register(YourModel, YourModelDefaultForm)

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CALC3KaeL2VefbA_GfkhaYf8jWJvr%3DsRLLjyP4FcHL9_q_EwfxA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Override the default form field for a model field

[James Pic]

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 know if it would
actually /increase/ the coupling.

Another way is to extract out all form related methods from model
fields (value_from_object(), save_form_data(), formfield()) into a new
class.

Then instead of this model:

dbfield -> model field <- formfield

You'd have:

form field
\
   modelformfield
  |
   model field
   /
dbfield

modelformfield would have the formfield(), value_from_object(), and
save_form_data().

Anyway, are you sure it's not another issue ? I mean, even if we
decide to move formfield(), shouldn't it have overridable defaults ?

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CALC3KaeDx%3DN0wb5t_LjxNPaSBZa_buZxS2RLCpgDN6yx87-JOw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[James Pic]

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 me
to where I was uncivil.

Best ;)

James

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CALC3KadbC%2B5QcScijB1a0yRFwuS9%3DRgXBdk8HrHaNvBy1qdWRA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[James Pic]

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 who only open issues and never submit a patch on github,
isn't that super annoying?
On Mar 16, 2016 5:38 AM, "Matías Iturburu"  wrote:

> I recently got stuck upgrading a project to 1.9 due to a lot of useful
> packages being not maintained:
>
> - django-endless-pagination: a substitute for django-pagination while it
> didn't had python3 support
> - django-taggit-templatetags: from when django-tagging didn't had python3
> support.
>
> django-registration was another must have that recently resurfaced but the
> same situation spawned django-registration-redux.
>
> Would it be too much a hassle to open an django-contrib organization with
> less friction provide support for orphaned projects?
>
> 2015-11-24 16:27 GMT-03:00 Marc Tamlyn :
>
>> This is something the core team discussed in Amsterdam. I believe there
>> was consensus to trial it with Django registration. I should catch up with
>> James and see if it is transferred. If this goes well I see no reason why
>> not.
>>
>> The biggest problem is the selection of packages, we have historically
>> wanted to avoid too much bikeshedding. Initially it's likely to be mostly
>> relatively inactive small utilities I think. But I think we are open to
>> being more risky here.
>>
>> M
>> On 24 Nov 2015 7:02 pm, "Asif Saifuddin"  wrote:
>>
>>> The projects will have the official tool status + the maintainer of the
>>> projects will be able to collaborate better with django core team? less
>>> risk of being abandoned by the maintainers etc.
>>>
>>> IMHO
>>>
>>> On Wed, Nov 25, 2015 at 12:31 AM, Collin Anderson 
>>> wrote:
>>>
 Hi,

 Say a little bit more: What would be the goal? What would you hope
 would be accomplished by doing this?

 Thanks,
 Collin

 On Tuesday, November 24, 2015 at 1:27:11 PM UTC-5, Asif Saifuddin wrote:
>
> How is the idea? tools like django-debug-toolbar, django-silk,
> django-taggit, django-filter etc and some more de facto tools under the
> umbrella of django github org?
>
> Regards
>
 --
 You received this message because you are subscribed to a topic in the
 Google Groups "Django developers (Contributions to Django itself)" group.
 To unsubscribe from this topic, visit
 https://groups.google.com/d/topic/django-developers/bIzfHebE2sw/unsubscribe
 .
 To unsubscribe from this group and all its topics, send an email to
 django-developers+unsubscr...@googlegroups.com.
 To post to this group, send email to django-developers@googlegroups.com
 .
 Visit this group at http://groups.google.com/group/django-developers.
 To view this discussion on the web visit
 https://groups.google.com/d/msgid/django-developers/70062405-3ccd-49b2-9118-ec1679203cd1%40googlegroups.com
 
 .

 For more options, visit https://groups.google.com/d/optout.

>>>
>>> --
>>> 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 post to this group, send email to django-developers@googlegroups.com.
>>> Visit this group at http://groups.google.com/group/django-developers.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/django-developers/CAKAqTgrnMoqy-%3DdDUx31Dgru6XTzT3e-T%3DhspY-CDK5tV9k1gQ%40mail.gmail.com
>>> 
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
>> 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 post to this group, send email to django-developers@googlegroups.com.
>> Visit this group at http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/CAMwjO1FzQ8cCgF7pR%2BRtPiSkNc5W4ipeWfwLz0hi4q_xzxZoAQ%40mail.gmail.com
>> 
>> .
>>
>> For more options, visit https://groups.google.com

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

[James Pic]

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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CALC3KaeqUamDV0PLOu4f0bW%2BpTyqV5B%3Dj6EwF_715pvuwkJ0Pg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Documentation for deployment on OpenShift Origin

[James Pic]

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:

https://github.com/political-memory/political_memory/blob/master/memopol/settings.py#L38-L46

You might be tempted to store it in an environment variable, but
that's not safe because environment variables are dumped in deployment
logs, like in their first example:

https://github.com/openshift/django-ex/blob/master/project/settings.py#L24-L28

In their other example (oh I found out they have two examples, more
confusion for users !), they use some sort of system to store the
secret key in a json file, that's a lot more complicated than it
should:

https://github.com/openshift/django-example/blob/master/wsgi/myproject/myproject/settings.py#L19-L28

By more complicated, I mean that it doesn't even work because it uses
a module that's not even in the repo anymore, so that won't even work.

For DEBUG, there's one example where they do DEBUG =
os.environ.get('DEBUG') == True, what happens if DEBUG is not set as
an environment variable ?

For static files, it's a bit more complicated on PaaS because you get
one persistent directory, where you want MEDIA_ROOT to be, and one
public directory, which is not served by the httpd. Their
configuration doesn't even include MEDIA_ROOT support BTW, again
there's only one way that works IMHO it's to symlink media from the
persistent dir into the "public" dir, and have STATIC_ROOT in a subdir
of the public dir - which again is not what they have.

And I could go on like this for a while heheh

Anyway, I'll try to contribute a new page about Django in the
devcenter repo ( https://github.com/openshift/devcenter ) and hope
they will want to merge it else I'll ask here again and as last resort
post it on my blog which I can't even get on djangoplanet even though
I asked several times in the past yearS.

Best ;)

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CALC3KafiFt9f6mku_gq%2BcS9yNPQq7%3DbLwWUz_3JNHaHMFRBgow%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Documentation for deployment on OpenShift Origin

[James Pic]

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 very good: it assumes the reader knows OpenShift very
well already on one hand, and it doesn't do Django very well on the
other hand (confused staticfiles configuration for example). A
documentation targeted at Django users who want to try to deploy on
OpenShift is missing IMHO.

I'm already doing some PRs to fix their example project which is the
official only thing I could find they have that would relate to
documentation so far, I also asked on their IRC channel if there's
anywhere I could contribute actual documentation.

Thanks for your feedback !

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CALC3KaeOSpuETVys7XHTdjx4-LPMs5nr%3DXPS0Y9KC10d34dAww%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Documentation for deployment on OpenShift Origin

[James Pic]

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 django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CALC3KaevEWQ-PHGMQfuaxPL%3D29tCOJQYR1QmzyPLGWGjQ4%2BJKw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Documentation for deployment on OpenShift Origin

[James Pic]

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 source projects
such as the political-memory project (mempol and compotista) and
django-autocomplete-light's test_project which are deployed by travis
when tests succeed. It's really changed my life as a django developer
and I'd like to share it with the community (reminds me about my post
on uWSGI on this list in 2011 heh).

I'd like to contribute documentation about deployment of Django
projects on OpenShift, would that be useful ?

Thanks

Best

-- 
http://yourlabs.org

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CALC3Kaek%3D-T_HR2fsOwHUwWqZ8Odz1B0_bEUTS_uKsjsPFJeKQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[James Pic]

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 django-reversion

> 3. Various 3rd party support (ex: django-reversion)

It's not that the admin supports it, it's that django-reversion
provides templates which support the admin.

> 4. Changelist filters / search / table sort

django-filter, django-haystack, django-tables2

> 5. Change form (save,save and continue, save and add another)

You can make your form view mixin with this

> 6. Delete confirmation displaying related objects that will get deleted
> along (though sometimes big and heavy)

Delete view requires confirmation - it probably requires post at least.

Hope this helps

Best

James

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CALC3KaeUJ62y5b%3DshH3jW2GkVe6fiXVxW-57aTqBE7ytWGenoA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Translate permission Django

[James Pic]

Perhaps django-modeltranslation could help too:
http://django-modeltranslation.readthedocs.org/en/latest/registration.html
(I really like this app BTW)

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CALC3KadDEK4RRGEFvzq3%2B_unf7ktd26rn1KF0CLr0Kvqpb-CMw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django startproject template enhancement proposal

[James Pic]

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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CALC3Kaf5QrgufVaUcZngD5oCDbV0sKm6Jr_Pa2hOQen2BgQZwQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Django startproject template enhancement proposal

[James Pic]

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 variables for everything to
override defaults.

Setup.py here allows:

- Adding an entry point,
- Installing all apps as packages,
- Installing test dependencies with extra_requires and pip install
project_name[test],
- Adding runtime dependencies.

For example, with that:

entry_points = {
'console_scripts': [
'project_name = project_name.manage:main',
],
},

And such a manage.py:

  def main():
os.environ.setdefault("DJANGO_SETTINGS_MODULE", "project_name.settings")
from django.core.management import execute_from_command_line
execute_from_command_line(sys.argv)

  if __name__ == "__main__":
main()

Installing the package will add the project_name command, allowing to
run `project_name migrate` for example from any directory.

I know it's too opinionated to add that to django, but I'd like to
open a discussion here and perhaps there's something we might find
worth changing in django's default project template.

Thanks for reading !

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CALC3Kacfi68SAA%3DC0AVX%2B3r8dPwOM3cJcBrdiC4CpZEF-NiCCg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Override the default form field for a model field

[James Pic]

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 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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CALC3Kaet9-Fy7BF64Fgtjh3MBz9EA7DR67FUkzhdS2HGg4821g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Override the default form field for a model field

[James Pic]

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 ?

- Select2WidgetForeignKey,
- Select2WidgetOneToOneField,
- Select2MultipleWidgetManyToManyField,
- HeavySelect2WidgetForeignKey,
- HeavySelect2WidgetOneToOneField,
- HeavySelect2MultipleWidgetManyToManyField

Also, wouldn't that require overriding the complete model class to
change the default widget for an external app ?

Also, would it be possible to conditionally enable Select2 widgets
depending whether select2 is in INSTALLED_APPS without changing the
model class ?

Or perhaps everybody would benefit from changing these hardcoded
values into attributes ?

> But that is actually the thing I don't like I think this needs to go:
> https://github.com/django/django/blob/d5f89ff6e873dbb2890ed05ce2aeae628792c8f7/django/db/models/fields/__init__.py#L869-L905

If that goes, so should save_form_data and value_from_object, that's
the first option I was talking about. I think we can still do that
later. Changing the hardcoded defaults into instance attributes would
still be useful when we do that.

>
> But at the end, I don't have a particular pain with all that. You can easily
> write your own model form, that changes the behavior. If you feel like
> changing it, go ahead, but I would welcome a removing the cross dependency.

There's got to be code that couples db fields and form fields, perhaps
it would help to move it around, but we'll also have to change it.

Again, I think both solutions are good here: we don't have to choose
one or another. When have the opportunity to do one before the other,
which benefits to django's stability because moving .formfield()
outside the model field is going to cause a lot of BC breaks in apps
and projects.

Thanks for sharing a bit of your time !

Best

-- 
http://yourlabs.org
Customer is king - Le client est roi - El cliente es rey.

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CALC3KadmQM6TmKsabD3yf5_r5cqa0JiEe%2BHZph8reTRe0iO%2BCg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Override the default form field for a model field

[James Pic]

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:
https://github.com/django/django/blob/d5f89ff6e873dbb2890ed05ce2aeae628792c8f7/django/forms/models.py#L101-L107
- ModelField.save_form_data() to save the form field's value, via
construct_instance and save_m2m:
https://github.com/django/django/blob/d5f89ff6e873dbb2890ed05ce2aeae628792c8f7/django/forms/models.py#L47-L63
https://github.com/django/django/blob/d5f89ff6e873dbb2890ed05ce2aeae628792c8f7/django/forms/models.py#L427-L446

To get the form field that's compatible with both ModelField methods,
it calls ModelField.formfield(), via fields_for_models, again in
django.forms.models:
https://github.com/django/django/blob/d5f89ff6e873dbb2890ed05ce2aeae628792c8f7/django/forms/models.py#L178

There's got to be somewhere to couple both the db field and the form
fields, and that seems to be in model fields. Note that ModelForm is
not in django.forms, but in django.forms.models. That module
encapsulates all coupling between django.forms and django.db.models.
Perhaps it would have been a bit more intuitive to have such a set of
modules: django.db, django.forms, django.models, django.models_forms.
That would be moving code around, but the code wouldn't change and the
result would be the same - so I figured when I gave it a try ;)

Anyway, I opened this topic because I thought it would be cool if we
could change the **default** formfield that is generated by
ModelForms. I know there are means to override the defaults, but that
means a lot of boilerplate code to override the form class every where
(views, admin, admin inlines ...). This feature is heavily used in DAL
v2 but really has nothing to do in an autocomplete app. It would be
nice if we could change the **default** formfields used by ModelForm,
from it's current logic "known-to-be-compatible", to an enhanced logic
"best for project". "Best for project" is defined by the
INSTALLED_APPS and the configuration these apps have. It would be
really cool to have these features in Django so that every app could
benefit from it because it would make form configuration a lot more
DRY. Currently in Django, even if a project defines its own ModelFormS
with their overrides (for every model), or even a custom
ModelFormMetaclass, users have to override everything in Django to use
that. This proposal is about allowing to change defaults.

I found two ways of achieving this, perhaps there are more:

- make ModelFormMetaclass more configurable (a PoC
https://github.com/jpic/xmodelform/blob/7de16ca1826c1bee91d9a5b616b78d3dff357fa4/xmodelform/forms.py#L118-L170
), but it's a bit more "fuzzy" to know if a form field is "compatible"
(as defined above) with the model field, unless we permit form fields
to override value_from_object() and save_form_data() which are
currently in model fields. Note that save_form_data() can be called
before or after form.save(), depending on wether it is a (many to many
field, virtual field) or not (
https://github.com/django/django/blob/d5f89ff6e873dbb2890ed05ce2aeae628792c8f7/django/forms/models.py#L438
). Also, we'd need a setting to allow a project to change what is the
default modelform class or metaclass it would use in django factories.

- add instance attributes for model fields to override the currently
hard coded defaults in formfield().

Unless we can get more of the community involved in this, is seems
more sane to go for the second option. The risk of doing something
wrong(tm) when changing hard coded defaults to attributes is None as
far as I understand.

Are there any better way to override **default** form fields generated
for models at the project-level ?

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CALC3Kae9vd2KY13nEaUjQV%3DYxP-aVNVY3DRBYPPgheF9u_81CQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Override the default form field for a model field

[James Pic]

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:
https://github.com/django/django/blob/master/django/db/models/fields/related.py#L945

Changing this to an attribute allows to replace it in an
AppConfig.ready() method as such:

class TestApp(AppConfig):
name = 'select2_one_to_one'

def ready(self):
model = self.get_model('TestModel')
# Perhaps that's the kind of nice place to override this
kind of things
model._meta.get_field('test').formfield_defaults['widget']
= forms.RadioSelect
# django-autocomplete-light users would execute something like:
model._meta.get_field('test').formfield_defaults['widget']
= autocomplete.Select2(url='my_autocomplete_url')

This also allows to change it when defining the field:

class TestModel(models.Model):
name = models.CharField(max_length=200)

test = models.OneToOneField(
'self',
null=True,
blank=True,
related_name='related_test_models',
# This seems like it would always be useful
formfield_defaults={
'widget': forms.RadioSelect
}
)

I checked that this changed rendering in the admin, and it felt pretty
awesome I recon, to see my override in the default form and inline
model forms too.

Here's what the poc patch looks like for ForeignKey (3 additions and 1
deletion, works on OneToOne field too):

https://github.com/jpic/django/commit/d102f362f3c1ceaf2d5224d71f788c0821a481ae

Of course, that works when the model field already supports a form
field. It doesn't solve the problem with virtual fields that don't
have a formfield() method like GenericForeignKey, where an app would
like to be able to provide a formfield() as well as logic for
modelfield.{value_from_object,save_form_data}(). Perhaps that's
something we could deal with later *if* we decide to deal with it ?

Meanwhile, could we perhaps start working on a consistent way to
configure formfield() in Django ? That doesn't solve all the use cases
I mentioned, but perhaps it would be a nice step forward.

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CALC3KaeBNZwpwrY0QRisKNGdD98_0iJV2%3DNrH5Nzkd-892Xakw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Override the default form field for a model field

[James Pic]

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 provide a
better form field or widget to select a particular model.

Now, it's a bit boilerplate to override the default generated form
field for a relation to that model in every modelform, as such:

class FirstForm(forms.ModelForm):
group = BetterField(your_options)

class SecondForm(forms.ModelForm):
main_group = BetterField(your_options)

# and so on

Currently, forms.ModelForm will use a form field that's known to work
by default. It does so by delegating that logic to the model field
methods such formfield() & friends.

Perhaps it would be an improvement if forms.ModelForm would be able to
use a form field that's *best* by default. "Best" here, is defined by
the project: what optional apps are installed and what configuration
they have.

For example, some apps will focus on providing a specific business
logic field, virtual or not (ie. generic many to many, array field,
tagfield ...), and other apps would focus on specific UX
(autocompletion, popup selection like raw_id_fields, other kind of
AJAX widgets). Gluing these apps in a projects is always the same,
from a project to another. If this kind of glue could be encapsulated
in another app, and made available in forms.ModelForm to improve
defaults, then users would have more time to work on what makes their
project different, rather than the same boilerplate code over and over
again.

I've been experimenting with ways to mitigate this issue for a few
years now, and here's what I came up with:

- allow a form field to override the model field's default saving
logic, as the input format may change it:
ModelField.value_from_object(), ModelField.save_form_data() and
ModelField.save_relation_data() should be overidable by the form
field,
- allow an app to register "form field factory callbacks" to ModelFormMetaclass

I've implemented all that in a separate app and experimented with it
for a while, and TBH it works and it's okay to have this in an
external app rather than in Django itself (PoC:
https://github.com/jpic/xmodelform ), even thought it implies that the
user has to override everything to use this ModelForm by default
(admin, views, forms ...), this is not known to have killed any kitten
so far. Unless some point out that it would be good to have it in
Django, I'd work on it in a separate app 

BUT, before I go all-in with this and make users use it by providing
it as the "official way", there's still one thing that fails to
convince me that it's the way to go. Something that may seem
completely unrelated, because it's a completely different way to go,
but solves the same issue: shouldn't effort be put in making a proper
way to change model fields from an external app ?

Related research on this has been started already apparently, with
django-swappable-models. It seems like work has been started to enable
model class override. While that's obviously overkill in the case I'm
talking about here, I'm wondering: would it be better to research a
way to enable external model field override, rather than the
form-oriented design exposed above (xmodelform) ?

I wish this could be avoided, but I recon that when you've tried
django-autocomplete-light v2's ModelForm, it's like eating the
defended fruit. Most of our userbase consider that v3 is not complete
and won't upgrade from v2 until they have this feature. I can
understand them, having a ModelForm that generates form fields which
are beyond "known to work" and have it generate "best" form fields for
a project without any boilerplate code is damn beautiful to see.
That's why this issue has been so fascinating to me and at least those
from the user base who stood up for that.

So, all this considered, what do you prefer, 0. research on overriding
the model field, or 1. on the model form ?

If 1., can we add the possibility to override the default ModelForm
class used by modelform_factory() and friends in Django ?

Thanks in advance for your guidance.

Best

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CALC3KaczUhnW4onQ%2B8qz3EZyHcD6%3Dxcap%2BPCuCxg6AvXCNRpCQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[James Pic]

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.
--- /home/jenkins/workspace/isort/django/contrib/sessions/backends/db.py:before
2016-02-01 16:04:24.701654
+++ /home/jenkins/workspace/isort/django/contrib/sessions/backends/db.py:after
2016-02-01 16:04:30.952126
@@ -1,8 +1,10 @@
 import logging

-from django.contrib.sessions.backends.base import CreateError,
SessionBase, UpdateError
+from django.contrib.sessions.backends.base import (
+CreateError, SessionBase, UpdateError,
+)
 from django.core.exceptions import SuspiciousOperation
-from django.db import IntegrityError, router, transaction, DatabaseError
+from django.db import DatabaseError, IntegrityError, router, transaction
 from django.utils import timezone
 from django.utils.encoding import force_text
 from django.utils.functional import cached_property

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CALC3Kadknk4-8N4CPPNC3_40rwQrSBrevqkKr9LE%2BswLMKG-3A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Extending ModelForm.save_m2m

[James Pic]

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. One might raise the point that
there should only be one way for a form to get / provide data for a
model field. While that makes sense, perhaps a pragmatic way to change
it would be useful.

Note that currently, I've tested the first idea (extension to
modelform api) and maybe it's not that bad
https://github.com/yourlabs/django-autocomplete-light/blob/v3/src/dal/forms.py#L60

Perhaps another way (deviated from the extension to modelform api)
would be to have forms.models.ModelField classes, which would add the
retrieve / provide data for a models.fields.Field and have precedence
over the corresponding
models.fields.Field.{save_form_data,value_for_object}:
https://gist.github.com/jpic/c30724a5a90b258a312a

Please let me know if there's anything else I can do to help getting feedback

Thanks for your feedback

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CALC3Kadkg%3D3osehZMXFzx7E0rPfwDLQVn5adiev5QUSAgRKONQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Extending ModelForm.save_m2m

[James Pic]

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 model
field in from FieldBase into ModelFormFieldBase while we're at it ?

I like this idea, are you more interrested in seeing a before / after
of 0. just moving value_from_object + save_form_data or 1. moving form
stuff from FieldBase into ModelFormFieldBase ?

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CALC3Kaf0g9%2B3FTibtYyi2_2AW%2BSmD8jYD6oCYYXTeSh_gN4DUA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Extending ModelForm.save_m2m

[James Pic]

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: validated input to business logic is in the model field.

It seems like decoupling the third feature from the model field into
its own component would be the best way to achieve loose coupling and
make it replaceable.

This would enable a user to replace the input-business behaviour
(value_from_object(), save_form_data()). This Having such an
input-business in a model field **or a modelform field** would allow
changing it on a per-form basis while keeping it in the right place.

Examples would be:

class YourModel(models.Model):
test = GenericForeignKey('content_type', 'object_id',
form_business=YourFormBusiness)

Alternatively:

class YourModelForm(models.Model):
test = YourField(form_business=YourFormBusiness)

Advantages:

- Model fields still have default save_form_data/value_from_object but
it's decoupled in another class,
- Form field still don't do any business logic, they may just provide
an alternative one,
- Allows providing form fields for model fields which are not editable
by default,
- Allows encapsulating form field specific business logic in its own class,

What do you think ?

Best

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CALC3KacNBZo6ezHtyMLLzpRd95D9EFUaX_PUr%2B5Vz12RR7a%3Ddw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Extending ModelForm.save_m2m

[James Pic]

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
abstracts a relation too, django-generic-m2m provides
RelatedObjectsDescriptor which abstracts a relation again.

While that works pretty well, it gets a bit complicated when it comes to
encapsulating the business logic for saving such data in a form object.
This is two-part problem:

- getting initial data,
- saving relations.

Currently in Django, getting initial data is done in model_to_dict, which
call's the model field's value_from_object() method, bypassing form fields
completely, I suggest that we add ability to do that in the Form field too.

As for saving relations, this is currently done in ModelForm.save_m2m(),
which calls the model field's save_form_data() directly, for each field
that's many to many or virtual, completely ignoring the form field.

This means that if one wants to customize how a form field works in terms
of getting the initial data for its widget and saving relations, then they
should override the model field, instead of just the form field. What could
go wrong with that ? :)

Do you think it would be OK to decouple that a bit and allow the form field
to have value_from_object() and save_form_data() ?

Best

James

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CALC3KadPbQ0xCLAZduQGjmAeiirjaaqOu5%3DP_Spu5K1TSPN3yQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Deprecate choices argument in Select.render

[James Pic]

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 django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CALC3Kaf8R08bn9izEiraJeKeAeg6c%3D896tGctdx89N_3kYVaKQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Deprecate choices argument in Select.render

[James Pic]

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 and all the sensible use cases for this have disappeared:
why would anyone do the effort of adding a widget-specific override in
Form.as_widget to add choices to rendering that won't even validate ?

Can we engage deprecation on the choices argument in render methods and
rely on self.choices only or am I missing something ?

If so, do you know if any work on this has been started ?

Best

James

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CALC3KacRiBEF3_0otH1jVw3Hg08SeyzberBv0p3bPWge4oTEAQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Generic M2M

[James Pic]

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 perhaps have multiple value support for raw_id_fields in the admin
to support it.

Would it be worth working on a DEP for this ?

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CALC3KaeVm0OMo3bZH25sR18Jq3M-4RriqMiE%3Dz89usAS5po_wQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Admin widget to display user_permissions in tabular format

[James Pic]

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 stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CALC3KafmyZiAWvCapjfO_ieWRY6N6pvi0OAjHQLbBEJ7kfjMbA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django 1.9 AppRegistryNotReady

[James Pic]

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 between apps, we've got inspiration from
django.shortcuts so we're trying to be consistent with django too.

FTR: 
http://blog.yourlabs.org/post/130026251348/django-19-support-for-django-autocomplete-light

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CALC3Kae7uXCZT30ufMnMDwHBSRrkUJW8ditaio%3DOEGGmwbV7hA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[James Pic]

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 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 ago, I've reproduce it in a test
>> project, you can see the result in the screenshot:
>>
>> https://github.com/jpic/double_readonly_field
>>
>> (Or just runserver and play with it).
>>
>> Since the description for this is a bit complicated and hard to search
>> ("overridden field in modelform used in modeladmin which name is
>> returned by get_readonly_fields"), I'm asking for your guidance:
>>
>> - has this already been reported ?
>> - is this tracked anywhere ?
>> - would anybody be interested in helping to fix this at the sprint ?
>>
>> Thanks a heap for your feedback,
>>
>> Again, sorry for not reporting this earlier,
>>
>> Best regards
>>
>> James (IRC: is_null)
>>
>> --
>> http://yourlabs.org
>> Customer is king - Le client est roi - El cliente es rey.
>>
>  --
> 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 post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/40964c44-f921-49c2-9414-f5f8c7a1de8c%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CALC3KafUiOEy5-e96tsX7GSdGTtOCt%2BaWv4jeDYRUSj%3D-tfJ_w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Read-only overridden field appears twice in the admin

[James Pic]

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 ago, I've reproduce it in a test
project, you can see the result in the screenshot:

https://github.com/jpic/double_readonly_field

(Or just runserver and play with it).

Since the description for this is a bit complicated and hard to search
("overridden field in modelform used in modeladmin which name is
returned by get_readonly_fields"), I'm asking for your guidance:

- has this already been reported ?
- is this tracked anywhere ?
- would anybody be interested in helping to fix this at the sprint ?

Thanks a heap for your feedback,

Again, sorry for not reporting this earlier,

Best regards

James (IRC: is_null)

-- 
http://yourlabs.org
Customer is king - Le client est roi - El cliente es rey.

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CALC3KafG19hJTx8qh5%2ByV8k165UvRyk2d7Hh%3D0tL-_tr72MZsw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Suggestions on a form library

[James Pic]

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  (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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CALC3KadKW%2BmvPvSnaqpB7-8XUN2XXYPWTFyZnu9CVmHHkxNQJA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Drop the TEMPLATE_DEBUG setting

[James Pic]

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 group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CALC3Kac%2B8O74YxCB2xS2k4LbXR1ivGRYnqbZ9nn8eLk8Ph4vMQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[James Pic]

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
> 2.7 and above, the stdlib's WSGIServer provides the needed functionality. You
> might want to investigate how (if) timeouts are set for Python>=2.7's
> WSGIServer -- at a glance, I didn't see any such thing in the Django code.

True, I added django 1.7 to my test matrix and have experienced no
such problem. As for Django < 1.7 well  the monkey patch is not
glorious: 
https://github.com/yourlabs/django-autocomplete-light/blob/v2/autocomplete_light/tests/widget.py#L14

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CALC3KaczaYpJO-MjKsJLKfi82yCY3BXuMM_vPor5-uWX5KFHJA%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Enable longer wait in StoppableWSGIServer.shutdown / hardcoded parameter

[James Pic]

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 enable configurable wait time in shutdown() ?

The we could use it like:

class WidgetTestCase(LiveServerTestCase)
shutdown_wait_time = 30 if os.environ.get('TRAVIS', False) else 2

What do you think ?

Thanks !

-- 
http://yourlabs.org
Customer is king - Le client est roi - El cliente es rey.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CALC3KafO%2BuxL0k4QQ5hZZvhXw2suWOpMpwmv9ubdROqLK%2Bj9HQ%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Working towards a simpler GCBV implementation?

[James Pic]

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 explicitly recommend to read the source code ?

Maybe it should recommend some links for users to sharpen their
understanding of GCBVs ?

Hope this helps

James

--
http://yourlabs.org

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CALC3Kae9MDguToPZ3kvRo5h_EQgvGywi4UU1_WNpFTXb39OZmw%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: AbstractUser to get more abstract

[James Pic]

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 overkill imho.

Did I miss anything critical ?

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: New contributor and Git

[James Pic]

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 message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

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

[James Pic]

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 login.
>
> Is there a reason to not scrub leading and trailing spaces from logon
> credentials
> in django.contrib.auth.forms.AuthenticationForm.clean? I guess that leading
> and trailing spaces would also have to be scrubbed when creating users as
> well


It's a frequent practice to use special characters including spaces as
prefix/suffix for passwords.

If you don't like it, you can override AuthenticationForm.

--
http://yourlabs.org
Customer is king - Le client est roi - El cliente es rey.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Django Admin Revamp - Any updates?

[James Pic]

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
- https://github.com/aobo711/bootstrap-django-admin
- I myself did such templates.

My thoughts, in case it helps:

- it takes just a few hours to convert Django admin to bootstrap, that's
probably why there are so many admin/bootstrap apps out there,
- but it's better to tweak colors, just converting the HTML to bootstrap
ends in a too "grayish", "sad" interface IMHO,
- it's a very popular demand - again that's why there are so many apps out
there,
- it's a great opportunity to make a cool navbar,
- forms don't have .as_bootstrap() method, but django-forms-bootstrap
provides |as_bootstrap. That's required for the admin/bootstrap integration
to be "perfect", but optional to make it "good enough".
- this can live in external apps anyway ...

-- 
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: Performance problems due to incorrect many-many primary key on many tables

[James Pic]

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  wrote:

> 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 marras, 21:11, Trey Raymond  wrote:
>> > Hi folks,
>> > I'm a DB engineer working for Yahoo, and we have a new product using
>> django
>> > that I'm onboarding.  We see a variety of easily fixed issues, but one
>> > major one - there are 21 many-many tables here, yet they have auto
>> > increment primary keys.  This of course is very slow on any platform,
>> but
>> > particularly can't use clustering on innodb (you can't, obviously, use
>> > myisam on a production system) and the performance of queries on these
>> > tables is severely degraded.  I can't onboard them properly until we fix
>> > these, but they claim the code throws errors when I do - I can't figure
>> out
>> > what could possibly reference the field, but something does.  If you
>> have
>> > any suggestions on an easy way (they have limited dev resources, and us
>> > DBE's can't work on code directly) to remove these references, a
>> setting or
>> > a very simple change, I'd appreciate it...also consider this a bug
>> report
>> > for future versions.
>>
>> The problem is that m2m relations are using Models in the underlying
>> implementation, and every Django model must have a single field
>> primary key. I have a feeling that any hack allowing the removal of
>> the redundant PK from m2m relations only is going to look really ugly.
>> Although I am more than happy if somebody proves me wrong...
>>
>> I do agree that the "id" primary key in m2m relations isn't necessary
>> and is bad for performance reasons for example. And that we should fix
>> this.
>>
>> The best way forward might be to make the ORM work with composite
>> primary keys. But we could still keep this non-public. There has been
>> some work to support composite primary keys in Django. I haven't
>> followed the work closely, but if I understand the situation correctly
>> one of the biggest problems is that making all of Django composite PK
>> friendly in one go is somewhat daunting. Actually, some parts of
>> Django do not work too nicely with non-integer or modifiable primary
>> keys.
>>
>> Of course after the ORM supports composite PKs then the next step
>> would be to make rest of Django support composite PKs, too, and have a
>> public API for composite PK models.
>>
>> All in all +1 to fixing this, but I am not sure what is the best way
>> to achieve this. Ideas welcome...
>>
>>  - Anssi
>>
>> --
>> 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.
>>
>>
>
>
> --
> http://yourlabs.org <http://blog.yourlabs.org>
> Customer is king - Le client est roi - El cliente es rey.
>



-- 
http://yourlabs.org <http://blog.yourlabs.org>
Customer is king - Le client est roi - El cliente es rey.

-- 
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: Performance problems due to incorrect many-many primary key on many tables

[James Pic]

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 marras, 21:11, Trey Raymond  wrote:
> > Hi folks,
> > I'm a DB engineer working for Yahoo, and we have a new product using
> django
> > that I'm onboarding.  We see a variety of easily fixed issues, but one
> > major one - there are 21 many-many tables here, yet they have auto
> > increment primary keys.  This of course is very slow on any platform, but
> > particularly can't use clustering on innodb (you can't, obviously, use
> > myisam on a production system) and the performance of queries on these
> > tables is severely degraded.  I can't onboard them properly until we fix
> > these, but they claim the code throws errors when I do - I can't figure
> out
> > what could possibly reference the field, but something does.  If you have
> > any suggestions on an easy way (they have limited dev resources, and us
> > DBE's can't work on code directly) to remove these references, a setting
> or
> > a very simple change, I'd appreciate it...also consider this a bug report
> > for future versions.
>
> The problem is that m2m relations are using Models in the underlying
> implementation, and every Django model must have a single field
> primary key. I have a feeling that any hack allowing the removal of
> the redundant PK from m2m relations only is going to look really ugly.
> Although I am more than happy if somebody proves me wrong...
>
> I do agree that the "id" primary key in m2m relations isn't necessary
> and is bad for performance reasons for example. And that we should fix
> this.
>
> The best way forward might be to make the ORM work with composite
> primary keys. But we could still keep this non-public. There has been
> some work to support composite primary keys in Django. I haven't
> followed the work closely, but if I understand the situation correctly
> one of the biggest problems is that making all of Django composite PK
> friendly in one go is somewhat daunting. Actually, some parts of
> Django do not work too nicely with non-integer or modifiable primary
> keys.
>
> Of course after the ORM supports composite PKs then the next step
> would be to make rest of Django support composite PKs, too, and have a
> public API for composite PK models.
>
> All in all +1 to fixing this, but I am not sure what is the best way
> to achieve this. Ideas welcome...
>
>  - Anssi
>
> --
> 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.
>
>


-- 
http://yourlabs.org 
Customer is king - Le client est roi - El cliente es rey.

-- 
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: testing tutorial feedback needed! (was: Testing documentation)

[James Pic]

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 about
setting up travis-ci (if the app is open source of course)

Keep up the great work !

-- 
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: I'd like to make a contribution to the wiki

[James Pic]

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 for answering


On Tue, Nov 27, 2012 at 3:57 PM, Harry Percival wrote:

> It's for promotional purposes really - I want to add my employers,
> PythonAnywhere, to the list of Django-Friendly-Web-Hosts
>
>
> https://code.djangoproject.com/wiki/DjangoFriendlyWebHosts
>
>
> But it's not entirely one-sided and evil-marketing-spammy.  We do offer
> Django hosting as part of our Free plan, so it's a nice place for people to
> come and try out Django, for free, maybe host a prototype web app...
>
> I'd be very happy help out more generally, by, say, cleaning up that page,
> fixing/removing broken links (I found a few), etc...
>
> I'd need WIKI_ADMIN privileges on the trac instance. my username is hjwp.
>
> rgds,
> Harry
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/django-developers/-/h6XZT7_QucIJ.
> 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.
>



-- 
http://yourlabs.org 
Customer is king - Le client est roi - El cliente es rey.

-- 
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: Improved ajax support idea

[James Pic]

Wow, thanks a lot.

I would like to thanks everybody who answered. I have learned a lot from
this thread and thanks to you I believe I am a better programmer.

FTR, I've added an article to my blog which obsoletes the previous article.

Kind regards from Spain


On Tue, Nov 27, 2012 at 8:22 PM, Javier Guerra Giraldez
wrote:

> On Sun, Nov 25, 2012 at 12:04 PM, James Pic  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 using database IDs.  any response that
> references server resources should send a whole URL. no need to
> construct them in the client.  check the HATEOAS principle.
>
> http://www.slideshare.net/trilancer/why-hateoas-1547275
>
>
>
> --
> Javier
>
> --
> 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.
>
>


-- 
http://blog.yourlabs.org
Customer is king - Le client est roi - El cliente es rey.

-- 
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.