There are two possible solutions, as I see it:
1. Change the default value of max_num from 0 to -1. That's a pretty
standard solution to indicating an "off" value for something with a
range of [0, ∞]. That way when max_num and extra are *both* explicitly
set to 0, the "Add Another" link could be removed. For the vast
majority of people who *don't* explicitly set max_num to 0, it would
be functionally identical to the current status of things in 1.2-beta.
It would also bring the javascript-enabled and noscript behaviors
closer into line with each other. Even better it means that the
behavior of extra is completely untouched. This solution would also
mean that max_num = 0 (which should be a valid value even if it's not
a common usage) is no longer ignored. Obviously the docs and tests
would be updated in conjunction with all that.
2. Create a readonly attribute for inlines as a completely new
feature. This would default to False, and setting it to True would
cause the desired behavior of preventing new inlines from being
created. It would override both extra and max_num. This solution would
be more explicit (as compared to the setting both max_num and extra to
0), but I feel it doesn't address the deeper issue around max_num.
I guess it ultimately comes down to wether you view this as a bug or a
feature. It has aspects of both. Calling it a "new" feature isn't
quite right because it already exists in 1.1, it just wasn't
intentional. If this is determined to be a feature, I'll open a new
bug ticket about max_num because I do think that should be corrected.
But it doesn't absolutely have to be corrected in connection with this
ticket.
Feedback?
- Gabriel
On Mar 16, 8:31 pm, Gabriel Hurley <[email protected]> wrote:
> Thanks for the IRC log, Ivan. That offers some perspective.
>
> Ideally a complete solution would have the following characteristics:
>
> 1. Makes behavior consistent with or without Javascript enabled. I
> personally would argue against any solution that caused extra and
> max_num to have different effects with and without JS.
>
> 2. Preserves existing behaviors from 1.1 for both extra and max_num.
> If those behaviors become "features" instead of "unintended side-
> effects" that's cool, but IMHO removing those behaviors doesn't
> benefit Django overall. Even if it means codifying the "feature" into
> something more like readonly that is no longer tied to max_num and
> extra.
>
> 3. Clarifies the meaning of max_num = 0. Currently max_num being 0 has
> a very odd behavior, and while it would be somewhat silly to create an
> Admin that had inlines but said the maximum number was 0, it seems
> equally strange that if I deliberately set max_num to 0 that it is, in
> fact, ignored.
>
> I guess in a sense, I really see three separate but related issues
> here. Anyhow, that's where I'm at with it. I'd love to hear from some
> of the core devs, since they've already given it some thought, and
> will make the ultimate decision about any changes that take place.
>
> - Gabriel
>
> On Mar 16, 7:56 pm, Iván Raskovsky <[email protected]> wrote:
>
>
>
> > Hi Gabriel, here's a follow up after I asked in django-dev if I should file
> > the ticket:http://botland.oebfare.com/logger/django-dev/2010/3/4/1/
> > Unfortunately I can't find my original conversation.
>
> > One thing that might be important to take into consideration is that without
> > the patch users without JS enabled can't add any new inlines, so if the
> > patch is rejected, we should be fixing that instead.
>
> > For what is worth, IMHO documented or not this was a behavior I'm sure I
> > wasn't the only one taking advantage of, and would very much like to see in
> > 1.2 so I can update my 1.1 projects and take advantage of all the new
> > features without breaking the actual functionality.
>
> > I'd like to take the opportunity and thank you for this patch and another
> > one in a ticket I filed. Thanks,
> > Iván
>
> > On Tue, Mar 16, 2010 at 8:10 PM, Gabriel Hurley <[email protected]> wrote:
> > > I couldn't help notice that #13023 was mentioned in Russ' latest 1.2
> > > status update as a ticket that "will require some significant design
> > > work". Since I've accepted that ticket I'd love to get some feedback
> > > from folks.
>
> > > The ticket:http://code.djangoproject.com/ticket/13023
>
> > > The ticket was opened because the new javascript "Add Another"
> > > functionality for admin inlines caused a useful (though possibly
> > > unintended) feature to be removed: when setting extra to 0 you could
> > > display existing inlines without allowing any new ones to be created.
> > > The new javascript made this impossible because the "Add Another"
> > > button was controlled by max_num, and ignored a value of 0.
>
> > > When I tracked back through the code, I realized there was a more
> > > fundamental problem: the javascript ignored a value of 0 because
> > > max_num has a default value of 0, and all the code using it had taken
> > > to equating max_num = 0 with being "off". So you can't actually have a
> > > maximum of 0. It's not possible.
>
> > > My patch for the ticket restored the desired behavior for admin
> > > inlines, but I'll admit it was a bit of a hack and didn't address the
> > > larger problem. I wasn't sure the larger problem was appropriate to
> > > fix in the 1.2 timeframe.
>
> > > So what is the appropriate course here? Should the default value and
> > > behavior of max_num be changed? Does the entire feature need to be re-
> > > evaluated? Are there other issues involved that I'm missing entirely?
>
> > > I'm happy to work on the ticket (and have a reasonable grasp on that
> > > area of the codebase), but I need some direction.
>
> > > Thanks so much!
>
> > > - Gabriel
>
> > > --
> > > You received this message because you are subscribed to the Google Groups
> > > "Django developers" group.
> > > To post to this group, send email to [email protected].
> > > To unsubscribe from this group, send email to
> > > [email protected]<django-developers%2Bunsubscr
> > > [email protected]>
> > > .
> > > For more options, visit this group at
> > >http://groups.google.com/group/django-developers?hl=en.
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
