Hi David,
Yep, I'm with you on this, another good reason to close this PR. I'm
building DAL's next feature on your fork, so you'll have my feedback
for sure at some point ;)
Best
<3
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions
Hi Jamesie,
I recently proposed adding a post_init signal for forms
(https://groups.google.com/forum/#!topic/django-developers/SviNiWy3Bjc).
Here's an example of how you might adjust the
forms:
https://github.com/seddonym/formsignals/blob/master/formsignals/priority/receivers.py
If such a sig
Ooops yes this is correct, it doesn't work in the advised file, apps.py
Thank you so much for your feedback, I need to ditch this patch just
find a way to make Django default usable date, time, image, relations
form fields useable ootb by marrying a JS framework.
Best
<3
--
You received this me
>
> About 1, if it's already working with a non-signal, how could it not work
> with a signal ? It is, after all, called from within formfield() in this
> implementation, so anything that's working today when formfield() is
> called, should work when formfield() emits a signal.
>
Signal handlers n
Hi Adam !
About 1, if it's already working with a non-signal, how could it not work
with a signal ? It is, after all, called from within formfield() in this
implementation, so anything that's working today when formfield() is
called, should work when formfield() emits a signal.
For 2 & 3, yes,
I've thought a bit more about this, and have had three ideas:
1. The signal idea doesn't seem likely to work in all cases due to import
order considerations. Forms can easily be imported during Django startup
whilst models, views, or urls, are imported, before AppConfig.ready() is
fired, which is
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 fr
>
> The ModelFormMetaclass usage you suggest is not supported by Django at
> this point
Sorry if I was unclear, I meant something like this (untested):
class MyModelFormMetaclass(ModelFormMetaclass):
"""
Customize the way our forms get built
"""
def __new__(*args, **kwargs):
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
I was suggesting in your project you subclass the ModelFormMetaclass, use
it in your own subclass of ModelForm, and use that everywhere in your
project.
Fatpage is an imaginary fork of flatpages that adds create and edit views
>
There are a lot of problems out there with imaginary third party a
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 n
Oh, I misunderstood, I thought you controlled both the models and forms but
wanted to enforce consistency. If you don't control the models (like
FlatPage), I presume you control the forms then?You can do it then with a
custom ModelForm subclass that overrides some of the building behaviour.
You
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.,
I've only skimmed the original thread so idk if the following was suggested
there. What I'd suggest for your project for the first condition is:
1. Subclass the model field you want to change and make it default to
having widget=RadioSelect:
class RadioSelectForeignKey(ForeignKey):
def formfi
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 soluti
Hi,
It's not clear to me whether or not this proposal considers the concerns
from the last time you raised the idea some months ago. Perhaps you could
summarize that discussion so we don't rehash it.
Thanks.
https://groups.google.com/d/topic/django-developers/zG-JvS_opi4/discussion
On Thursd
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 c
17 matches
Mail list logo
