Re: Displaying (some) M2M fields with through models specified
Thanks Russ, I missed #9475 in my search. I'll have a read through those tickets... ...and back. I'm leaning towards keeping the API as-is, with add/create/remove simply unavailable or raising exceptions if the intermediate model doesn't meet the requirements. A few reasons: 1. As the discussions show, the best form of this API is not obvious, which makes me think maybe there isn't a best form of this API. 2. create and add/remove would either have to have different ways of going about this or inherent corner cases, since create uses arbitrary keyword args, while add/remove use arbitrary positional args. How do you create a relationship to a new model which has a field called "extra"? 3. Although an inconsistency would remain in that only some m2m fields can use add/create/remove, I think this is a reasonable one. The difference between the presence or absence of at least one non-default field is quite easy to grasp and explain: either you need to provide extra data, or you don't. Having behaviour split along a clear line like that is acceptable IMO. The m2m relationships which can and can't be used with the default admin would match this. 4. Nothing is possible with this that isn't possible in roughly the same amount of code using the existing methods provided by related managers and intermediate model managers (albeit arguably less clearly). All that said I'm not really against changing the API. I just don't see a compelling reason to do so, especially absent an API everyone can agree on. For now, I'm keen to fix what I see as an unreasonable inconsistency: the fact that auto-compatible intermediate models can't do everything auto-created models can :) If this works, it's accidental, and I'd be *very* surprised if the final > fix is as simple as this. auto_created is involved with the process that > determines whether a table is synchronised; so while it probably works if > you add `auto_created = True` to a table that has already been > synchronised, you'll probably find that it breaks if you do this on an > unsynchronised model (with "can't find table" type errors). > You're 100% right - it "works" in the sense that once your model is set up correctly, you can delete all your custom admin form code and just add auto_created = True to your intermediate model's Meta. That's what I just did, and it felt great. This should be possible to auto detect - a manual flag shouldn't be > required. There's enough data in the Options object on a model to determine > if an m2m instance can be saved without any data beyond the PKs of the two > related objects. > I thought having the user specify their intention might be a good idea because: - you can check at startup time whether or not things are going to work as they expect - existing projects' behaviour won't change in any way - these fields would end up being rendered with no way to modify the through model's extra fields, which might be a bit baffling. Then again, no more baffling than having them just not show up at all like they do now - either way it's a trip to Google. These are all pretty minor so I guess in order to reduce churn they could just be ignored. I'm all for fewer pointless options; if you're OK with no flag then so am I. In summary - you're on the right path. There's a few edge cases that need > to be addressed, and from a "greedy core developer" point of view, it would > be nice to see the *whole* problem solved, not just the subset you've > restricted yourself to. However, I'm sure we'll take whatever patch we can > get :-) > Thanks again for taking a look at this, Russ. Alex On Monday, May 26, 2014 2:17:10 PM UTC+8, Russell Keith-Magee wrote: > > Hi Alex, > > Short version - Broadly speaking, this is a feature we've discussed many > times over many years, and we've accepted as a good idea in principle. It's > logged as ticket #9475 [1]. There is some additional discussion on the > original ticket that introduced m2m through models (#6095 [2]). > > The devil is in the details. Your analysis is largely correct, but there > are a couple of details in your analysis that need tweaking. > > On Mon, May 26, 2014 at 1:55 PM, Alexander Hill > > > wrote: > >> Hi all, >> >> Currently, only M2M fields without custom intermediary models can use the >> normal Django M2M form machinery. If you define your own intermediary >> models, you need to use inlines instead. >> >> I would like to allow fields with custom through models to use the >> regular M2M field/widget automatically, if the through model meets the >> requirement that all its extra fields either have defaults or are nullable. >> I'll refer to these as "auto-compatible" models. >> > > It's not *just* about the admin interface, however. Admin only works > because there's an underlying API that can be used; we need an API proposal > to underpin the m2m widget used by admin. This was the sticking point that > prevented this featur
FormWizard needs confirmation step logic. ticket #21644
Hello, I have posted an implementation/proof of concept to ticket 21644 (https://code.djangoproject.com/ticket/21644). The implementation is currently written as a mixin because I need to be able to use it now and I don't like maintaining a custom fork of django for my projects. If changed to update the base classes directly, the diff would be minimal. I am happy to work on FormWizard improvements because they are particularly useful for some of my projects, but I haven't had much of a response. Since this is a contrib app bundled with django, I am hesitant to spend too much time on it without some sort of positive and/or constructive feedback from someone who can accept the changes. On topic... the brief summary for #21644 is that this allows for "confirmation" steps in a formwizard that have access to the data submitted for previous steps. This is required for something like a checkout confirmation or anything where the user needs to be presented with data entered previously for acceptance to be meaningful. It was important to my use case that the wizard supports multiple confirmation steps. I've used a base class that confirmation forms should inherit from to detect when confirmation logic should be used. This allows for a backwards compatible opt-in approach. Thanks, Gordon -- 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/c50ed39a-70a6-436e-8afa-d2ddb1325908%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: FormWizard needs confirmation step logic. ticket #21644
My observation is that not many core developers seem interested in contrib.formtools these days. It was added by Adrian in 2006, but as far as I can see from the commit history, it hasn't received much love lately. If would be a good candidate for deprecation from Django itself, in my opinion. On Monday, May 26, 2014 3:32:41 PM UTC-4, Gordon wrote: > > Hello, > > I have posted an implementation/proof of concept to ticket 21644 ( > https://code.djangoproject.com/ticket/21644). The implementation is > currently written as a mixin because I need to be able to use it now and I > don't like maintaining a custom fork of django for my projects. If changed > to update the base classes directly, the diff would be minimal. > > I am happy to work on FormWizard improvements because they are > particularly useful for some of my projects, but I haven't had much of a > response. Since this is a contrib app bundled with django, I am hesitant > to spend too much time on it without some sort of positive and/or > constructive feedback from someone who can accept the changes. > > On topic... the brief summary for #21644 is that this allows for > "confirmation" steps in a formwizard that have access to the data submitted > for previous steps. This is required for something like a checkout > confirmation or anything where the user needs to be presented with data > entered previously for acceptance to be meaningful. It was important to my > use case that the wizard supports multiple confirmation steps. I've used a > base class that confirmation forms should inherit from to detect when > confirmation logic should be used. This allows for a backwards compatible > opt-in > approach. > > Thanks, > Gordon > -- 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/2e92d0ca-bd65-46cc-a061-1d29f975aa09%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: FormWizard needs confirmation step logic. ticket #21644
On Monday, May 26, 2014 6:04:31 PM UTC-4, Tim Graham wrote: > > My observation is that not many core developers seem interested in > contrib.formtools these days. It was added by Adrian in 2006, but as far as > I can see from the commit history, it hasn't received much love lately. If > would be a good candidate for deprecation from Django itself, in my opinion. > > On Monday, May 26, 2014 3:32:41 PM UTC-4, Gordon wrote: >> >> Hello, >> >> I have posted an implementation/proof of concept to ticket 21644 ( >> https://code.djangoproject.com/ticket/21644). The implementation is >> currently written as a mixin because I need to be able to use it now and I >> don't like maintaining a custom fork of django for my projects. If changed >> to update the base classes directly, the diff would be minimal. >> >> I am happy to work on FormWizard improvements because they are >> particularly useful for some of my projects, but I haven't had much of a >> response. Since this is a contrib app bundled with django, I am hesitant >> to spend too much time on it without some sort of positive and/or >> constructive feedback from someone who can accept the changes. >> >> On topic... the brief summary for #21644 is that this allows for >> "confirmation" steps in a formwizard that have access to the data submitted >> for previous steps. This is required for something like a checkout >> confirmation or anything where the user needs to be presented with data >> entered previously for acceptance to be meaningful. It was important to my >> use case that the wizard supports multiple confirmation steps. I've used a >> base class that confirmation forms should inherit from to detect when >> confirmation logic should be used. This allows for a backwards >> compatible opt-in approach. >> >> Thanks, >> Gordon >> > Fair enough and thanks for the reply. That is too bad though. I've seen a good number of 3rd party apps that would benefit from using the NamedUrlWizardView ( https://docs.djangoproject.com/en/dev/ref/contrib/formtools/form-wizard/#usage-of-namedurlwizardview ). -- 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/5476d56f-39e4-4078-beb5-f2801751728b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: FormWizard needs confirmation step logic. ticket #21644
If we did split it out, would you be interested in being a maintainer? On Monday, May 26, 2014 6:51:13 PM UTC-4, Gordon wrote: > > > > On Monday, May 26, 2014 6:04:31 PM UTC-4, Tim Graham wrote: >> >> My observation is that not many core developers seem interested in >> contrib.formtools these days. It was added by Adrian in 2006, but as far as >> I can see from the commit history, it hasn't received much love lately. If >> would be a good candidate for deprecation from Django itself, in my opinion. >> >> On Monday, May 26, 2014 3:32:41 PM UTC-4, Gordon wrote: >>> >>> Hello, >>> >>> I have posted an implementation/proof of concept to ticket 21644 ( >>> https://code.djangoproject.com/ticket/21644). The implementation is >>> currently written as a mixin because I need to be able to use it now and I >>> don't like maintaining a custom fork of django for my projects. If changed >>> to update the base classes directly, the diff would be minimal. >>> >>> I am happy to work on FormWizard improvements because they are >>> particularly useful for some of my projects, but I haven't had much of a >>> response. Since this is a contrib app bundled with django, I am hesitant >>> to spend too much time on it without some sort of positive and/or >>> constructive feedback from someone who can accept the changes. >>> >>> On topic... the brief summary for #21644 is that this allows for >>> "confirmation" steps in a formwizard that have access to the data submitted >>> for previous steps. This is required for something like a checkout >>> confirmation or anything where the user needs to be presented with data >>> entered previously for acceptance to be meaningful. It was important to my >>> use case that the wizard supports multiple confirmation steps. I've used a >>> base class that confirmation forms should inherit from to detect when >>> confirmation logic should be used. This allows for a backwards >>> compatible opt-in approach. >>> >>> Thanks, >>> Gordon >>> >> > > > Fair enough and thanks for the reply. That is too bad though. I've seen > a good number of 3rd party apps that would benefit from using the > NamedUrlWizardView ( > https://docs.djangoproject.com/en/dev/ref/contrib/formtools/form-wizard/#usage-of-namedurlwizardview > ). > -- 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/c1e36882-082d-4f33-8b4b-57daf381e141%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Schema tests and .extra queryset method
Hi Maximiliano, Sorry for the delay in responding to this. On Thursday 22 May 2014 17:06:23 Maximiliano Robaina wrote: > El jueves, 22 de mayo de 2014 03:24:12 UTC-3, Shai Berger escribió: > > > > Quoting it uncoditionally would break the test on Oracle (which, by > > default, turns all the names to uppercase). There is a feature-flag for > > it... > > How this feature flag should works? It's called "uppercases_column_names". The way it should work is -- it should be False for backends that don't change the case of names, and True for Oracle (currently, it is actually reversed; fixing it is on my to-do, but I haven't gotten to it yet). > I see that Oracle backend is always making an upper in > DatabaseOperations.quote_name, therefore, how does Oracle pass test like > [1] where it is using field name in lowecase [2] ? > > [1] https://github.com/django/django/blob/1.7b4/tests/schema/tests.py#L152 > [2] https://github.com/django/django/blob/1.7b4/tests/schema/tests.py#L172 > It lowercases the name back in introspection https://github.com/django/django/blob/1.7b4/django/db/backends/oracle/introspection.py#L62 And yes, this behavior completely breaks things if you try to really use lowercase in names. I am on record describing the Oracle backend's behavior as "case-insane", but this cannot be changed without breaking backwards compatibility. (FWIW, I believe the SQL standard says that unquoted names should be case- insensitive, which, in turn, means introspection more-or-less must be broken. uppercasing unquoted input was standard back in the 1960s -- it was an easy way to differentiate user input from computer output in a time when the interface was a one-color, one-font teletype. Regretfully, we now need to deal with the consequences.) Shai. -- 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/201405270316.45572.shai%40platonix.com. For more options, visit https://groups.google.com/d/optout.
