I'm aware of the current timeline of the 1.2 release, and thus I want
to clarify the definition of non-trivial in this case:
I've written a 'TiledInline', subclass to
django.contrib.admin.options.InlineModelAdmin. It adds the ability to
enhance the StackedInline such that formsets become "cards" or "tiles"
which pile up horizontally until forced to break the line to another
row. This is intense value to my company's use of the Admin site.
Monitors are often not wide enough to graciously display all needed
fields with the Tabular Inline, and the StackedInline wastes a good
amount of space. The idea of the TileInline was to let those little
StackedInlines get their widths automatically from contained content,
thus opening up the otherwise unused space to fit another column of
TileInline formsets.
I've searched around online a bit and can't seem to find much of
anything that clearly adds this usability tweak. (That's my attempt
to illustrate that this hasn't been discussed before. Correct me if
I'm wrong.) My reasoning for adding it to the trunk is that there is
currently not an InlineModelAdmin that addresses the need to leverage
both vertical and horizontal sizing; StackedInline goes vertical,
while TabularInline goes horizontal, but neither one maintains
usability once an inline displays more than four or five fields (most
notably simple CharFields, whose widgets are fairly wide in a
TabularInline on a non-widescreen monitor).
The change is primarily a mere CSS difference from the StackedInline,
but I made a new template for it once I decided to add a toggle switch
to the main inline formset, for switching back and forth from a
traditional StackedInline to TileInline. This leads to another tweak,
where the new TileInline can then accept an option "tiled_by_default",
which may be set to True or False, according to the desired default
functionality of the inline.
Short story made shorter, I wanted to submit this as a patch for
consideration, and felt it a good idea to first ask if this is "non-
trivial", since, according to the instructions on patch submissions,
things that are "more than a simple bug fix, ... introduc[ing] Django
functionality" deserve mention on the developers list.
I can provide more details, if requested, including the small svn-diff
file, which alters:
* /trunk/django/contrib/admin/options.py, to add 3 lines for
TiledInline
* /trunk/django/contrib/admin/__init__.py, to include the import of
TiledAdmin for uniform use with StackedInline and TabularInline
* /trunk/django/contrib/admin/templates/admin/edit_inline/
tiled.html, a template with a few small changes from StackedInline
* /trunk/django/contrib/media/css/forms.css, to add a few lines
leveraging a ".tiled" class found in the above-noted new template
On Fri, Nov 6, 2009 at 4:41 PM, Tim <tonightslasts...@gmail.com> wrote:
> I'm aware of the current timeline of the 1.2 release, and thus I want
> to clarify the definition of non-trivial in this case:
> I've written a 'TiledInline', subclass to
> django.contrib.admin.options.InlineModelAdmin. It adds the ability to
> enhance the StackedInline such that formsets become "cards" or "tiles"
> which pile up horizontally until forced to break the line to another
> row. This is intense value to my company's use of the Admin site.
> Monitors are often not wide enough to graciously display all needed
> fields with the Tabular Inline, and the StackedInline wastes a good
> amount of space. The idea of the TileInline was to let those little
> StackedInlines get their widths automatically from contained content,
> thus opening up the otherwise unused space to fit another column of
> TileInline formsets.
> I've searched around online a bit and can't seem to find much of
> anything that clearly adds this usability tweak. (That's my attempt
> to illustrate that this hasn't been discussed before. Correct me if
> I'm wrong.) My reasoning for adding it to the trunk is that there is
> currently not an InlineModelAdmin that addresses the need to leverage
> both vertical and horizontal sizing; StackedInline goes vertical,
> while TabularInline goes horizontal, but neither one maintains
> usability once an inline displays more than four or five fields (most
> notably simple CharFields, whose widgets are fairly wide in a
> TabularInline on a non-widescreen monitor).
> The change is primarily a mere CSS difference from the StackedInline,
> but I made a new template for it once I decided to add a toggle switch
> to the main inline formset, for switching back and forth from a
> traditional StackedInline to TileInline. This leads to another tweak,
> where the new TileInline can then accept an option "tiled_by_default",
> which may be set to True or False, according to the desired default
> functionality of the inline.
> Short story made shorter, I wanted to submit this as a patch for
> consideration, and felt it a good idea to first ask if this is "non-
> trivial", since, according to the instructions on patch submissions,
> things that are "more than a simple bug fix, ... introduc[ing] Django
> functionality" deserve mention on the developers list.
> I can provide more details, if requested, including the small svn-diff
> file, which alters:
> * /trunk/django/contrib/admin/options.py, to add 3 lines for
> TiledInline
> * /trunk/django/contrib/admin/__init__.py, to include the import of
> TiledAdmin for uniform use with StackedInline and TabularInline
> * /trunk/django/contrib/admin/templates/admin/edit_inline/
> tiled.html, a template with a few small changes from StackedInline
> * /trunk/django/contrib/media/css/forms.css, to add a few lines
> leveraging a ".tiled" class found in the above-noted new template
> Many thanks for all of the hard work :)
> Tim
This sounds interesting, but I'm having a hard time visualizing it,
any chance you could provide some screenshots? As for whether it
should be included I'd say the first step is to get it out there in an
app anyone can download, as things like this can live outside of
Django. Second, if you are serious about getting this included in
Django I'd file a bug and upload a patch, it's much easier to discuss
these things when there's something concrete on the table.
Alex
-- "I disapprove of what you say, but I will defend to the death your
right to say it." -- Voltaire
"The people's good is the highest law." -- Cicero
"Code can always be simpler than you think, but never as simple as you
want" -- Me
I truly find this most useful when dealing with TextFields, like I
mention in the blog post, because if you get 5 or 6 of those together,
they get really wide really fast, and neither the Stacked nor Tabular
really suits the situation, in terms of usability.
> As for whether it
> should be included I'd say the first step is to get it out there in an
> app anyone can download, as things like this can live outside of
> Django.
Yeah, with the blog post there is a zip file download. It's not
really in an "app" form, but that can be done fairly easily. I shall
put one together, for the sake of getting it working as close to zero-
config as possible.
Thanks much for the reply. Glad to hear some interest.
> Second, if you are serious about getting this included in
> Django I'd file a bug and upload a patch, it's much easier to discuss
> these things when there's something concrete on the table.
> Alex
> --
> "I disapprove of what you say, but I will defend to the death your
> right to say it." -- Voltaire
> "The people's good is the highest law." -- Cicero
> "Code can always be simpler than you think, but never as simple as you
> want" -- Me
Wouldn't be the 'new inlines' [1] of GSoC admin improvements a nice
approach? The height is fixed, no waste of space... And no need to have
blank fieldsets for new objects (the 'extra' inline option).
But anyway sometimes Stacked and Tabular just don't fit, it's nice to have
another way to show related objects.
On Fri, Nov 6, 2009 at 11:59 PM, Tim <tonightslasts...@gmail.com> wrote:
> On Nov 6, 6:20 pm, Alex Gaynor <alex.gay...@gmail.com> wrote:
> > This sounds interesting, but I'm having a hard time visualizing it,
> > any chance you could provide some screenshots?
> I truly find this most useful when dealing with TextFields, like I
> mention in the blog post, because if you get 5 or 6 of those together,
> they get really wide really fast, and neither the Stacked nor Tabular
> really suits the situation, in terms of usability.
> > As for whether it
> > should be included I'd say the first step is to get it out there in an
> > app anyone can download, as things like this can live outside of
> > Django.
> Yeah, with the blog post there is a zip file download. It's not
> really in an "app" form, but that can be done fairly easily. I shall
> put one together, for the sake of getting it working as close to zero-
> config as possible.
> Thanks much for the reply. Glad to hear some interest.
> Tim
> > Second, if you are serious about getting this included in
> > Django I'd file a bug and upload a patch, it's much easier to discuss
> > these things when there's something concrete on the table.
> > Alex
> > --
> > "I disapprove of what you say, but I will defend to the death your
> > right to say it." -- Voltaire
> > "The people's good is the highest law." -- Cicero
> > "Code can always be simpler than you think, but never as simple as you
> > want" -- Me
I very much like the look of that one, but I'm not sure if it
completely fills the need I want for my own project. All of the
fields need to be quickly visible, without needing to know the
rendered name of the instance.
Those 'new inlines' address the problem of space, but they cater to
those who already know what they're looking for. My coworkers need to
constantly look over lists of location addresses, and require that all
the fields are displayed for quick scanning. In other words, the
users of this particular admin page will rely very heavily on it to
show them all the data at all times.
Another improvement to inlines in general would be to make them
sortable. There are some Javascript enhancements out there for
sorting HTML tables by any column, by clicking on its <th> tag. The
'new inlines' don't really allow for this possibility.
Again, thanks for the feedback! I should play more with those new
inlines. I really do think that there is potential there, as with
most of the wonderful things that come from GSoC.
Tim
On Nov 7, 5:23 am, Renato Garcia Pedigoni <renatopedig...@gmail.com>
wrote:
> Wouldn't be the 'new inlines' [1] of GSoC admin improvements a nice
> approach? The height is fixed, no waste of space... And no need to have
> blank fieldsets for new objects (the 'extra' inline option).
> But anyway sometimes Stacked and Tabular just don't fit, it's nice to have
> another way to show related objects.
> On Fri, Nov 6, 2009 at 11:59 PM, Tim <tonightslasts...@gmail.com> wrote:
> > On Nov 6, 6:20 pm, Alex Gaynor <alex.gay...@gmail.com> wrote:
> > > This sounds interesting, but I'm having a hard time visualizing it,
> > > any chance you could provide some screenshots?
> > There are a couple of screenshots listed there.
> > I truly find this most useful when dealing with TextFields, like I
> > mention in the blog post, because if you get 5 or 6 of those together,
> > they get really wide really fast, and neither the Stacked nor Tabular
> > really suits the situation, in terms of usability.
> > > As for whether it
> > > should be included I'd say the first step is to get it out there in an
> > > app anyone can download, as things like this can live outside of
> > > Django.
> > Yeah, with the blog post there is a zip file download. It's not
> > really in an "app" form, but that can be done fairly easily. I shall
> > put one together, for the sake of getting it working as close to zero-
> > config as possible.
> > Thanks much for the reply. Glad to hear some interest.
> > Tim
> > > Second, if you are serious about getting this included in
> > > Django I'd file a bug and upload a patch, it's much easier to discuss
> > > these things when there's something concrete on the table.
> > > Alex
> > > --
> > > "I disapprove of what you say, but I will defend to the death your
> > > right to say it." -- Voltaire
> > > "The people's good is the highest law." -- Cicero
> > > "Code can always be simpler than you think, but never as simple as you
> > > want" -- Me
> I very much like the look of that one, but I'm not sure if it
> completely fills the need I want for my own project. All of the
> fields need to be quickly visible, without needing to know the
> rendered name of the instance.
> Those 'new inlines' address the problem of space, but they cater to
> those who already know what they're looking for. My coworkers need to
> constantly look over lists of location addresses, and require that all
> the fields are displayed for quick scanning. In other words, the
> users of this particular admin page will rely very heavily on it to
> show them all the data at all times.
> Another improvement to inlines in general would be to make them
> sortable. There are some Javascript enhancements out there for
> sorting HTML tables by any column, by clicking on its <th> tag. The
> 'new inlines' don't really allow for this possibility.
> Again, thanks for the feedback! I should play more with those new
> inlines. I really do think that there is potential there, as with
> most of the wonderful things that come from GSoC.
> Tim
> On Nov 7, 5:23 am, Renato Garcia Pedigoni <renatopedig...@gmail.com>
> wrote:
> > Hi Tim
> > Wouldn't be the 'new inlines' [1] of GSoC admin improvements a nice
> > approach? The height is fixed, no waste of space... And no need to have
> > blank fieldsets for new objects (the 'extra' inline option).
> > But anyway sometimes Stacked and Tabular just don't fit, it's nice to have
> > another way to show related objects.
> > On Fri, Nov 6, 2009 at 11:59 PM, Tim <tonightslasts...@gmail.com> wrote:
> > > On Nov 6, 6:20 pm, Alex Gaynor <alex.gay...@gmail.com> wrote:
> > > > This sounds interesting, but I'm having a hard time visualizing it,
> > > > any chance you could provide some screenshots?
> > > There are a couple of screenshots listed there.
> > > I truly find this most useful when dealing with TextFields, like I
> > > mention in the blog post, because if you get 5 or 6 of those together,
> > > they get really wide really fast, and neither the Stacked nor Tabular
> > > really suits the situation, in terms of usability.
> > > > As for whether it
> > > > should be included I'd say the first step is to get it out there in an
> > > > app anyone can download, as things like this can live outside of
> > > > Django.
> > > Yeah, with the blog post there is a zip file download. It's not
> > > really in an "app" form, but that can be done fairly easily. I shall
> > > put one together, for the sake of getting it working as close to zero-
> > > config as possible.
> > > Thanks much for the reply. Glad to hear some interest.
> > > Tim
> > > > Second, if you are serious about getting this included in
> > > > Django I'd file a bug and upload a patch, it's much easier to discuss
> > > > these things when there's something concrete on the table.
> > > > Alex
> > > > --
> > > > "I disapprove of what you say, but I will defend to the death your
> > > > right to say it." -- Voltaire
> > > > "The people's good is the highest law." -- Cicero
> > > > "Code can always be simpler than you think, but never as simple as you
> > > > want" -- Me
I'm aware that the admin-ui branch is to be folded into the 1.2
release of Django-- I'm not very familiar with the branch, and
docmentation is hard to find on it (in my opinion), short of running
the branch myself. Will it replace the need for the current
InlineModelAdmin subclasses entirely? I know that I can just go try
the branch myself, but that's a bit of a sidequest for just wanting
inlines to stop running off the side of the page :)
Looking forward to the implementations of the things pointed out
here. Conclusively, there's only a very diminished need for
alternative InlineModelAdmin subclasses, until 1.2 graces us with some
new approaches.
Tim
On Nov 8, 10:44 am, andybak <andy...@gmail.com> wrote:
> I'm pretty sure Zain has made all the inline types sortable on his
> admin-ui branch.
> On Nov 8, 7:58 am, Tim <tonightslasts...@gmail.com> wrote:
> > I very much like the look of that one, but I'm not sure if it
> > completely fills the need I want for my own project. All of the
> > fields need to be quickly visible, without needing to know the
> > rendered name of the instance.
> > Those 'new inlines' address the problem of space, but they cater to
> > those who already know what they're looking for. My coworkers need to
> > constantly look over lists of location addresses, and require that all
> > the fields are displayed for quick scanning. In other words, the
> > users of this particular admin page will rely very heavily on it to
> > show them all the data at all times.
> > Another improvement to inlines in general would be to make them
> > sortable. There are some Javascript enhancements out there for
> > sorting HTML tables by any column, by clicking on its <th> tag. The
> > 'new inlines' don't really allow for this possibility.
> > Again, thanks for the feedback! I should play more with those new
> > inlines. I really do think that there is potential there, as with
> > most of the wonderful things that come from GSoC.
> > Tim
> > On Nov 7, 5:23 am, Renato Garcia Pedigoni <renatopedig...@gmail.com>
> > wrote:
> > > Hi Tim
> > > Wouldn't be the 'new inlines' [1] of GSoC admin improvements a nice
> > > approach? The height is fixed, no waste of space... And no need to have
> > > blank fieldsets for new objects (the 'extra' inline option).
> > > But anyway sometimes Stacked and Tabular just don't fit, it's nice to have
> > > another way to show related objects.
> > > On Fri, Nov 6, 2009 at 11:59 PM, Tim <tonightslasts...@gmail.com> wrote:
> > > > On Nov 6, 6:20 pm, Alex Gaynor <alex.gay...@gmail.com> wrote:
> > > > > This sounds interesting, but I'm having a hard time visualizing it,
> > > > > any chance you could provide some screenshots?
> > > > There are a couple of screenshots listed there.
> > > > I truly find this most useful when dealing with TextFields, like I
> > > > mention in the blog post, because if you get 5 or 6 of those together,
> > > > they get really wide really fast, and neither the Stacked nor Tabular
> > > > really suits the situation, in terms of usability.
> > > > > As for whether it
> > > > > should be included I'd say the first step is to get it out there in an
> > > > > app anyone can download, as things like this can live outside of
> > > > > Django.
> > > > Yeah, with the blog post there is a zip file download. It's not
> > > > really in an "app" form, but that can be done fairly easily. I shall
> > > > put one together, for the sake of getting it working as close to zero-
> > > > config as possible.
> > > > Thanks much for the reply. Glad to hear some interest.
> > > > Tim
> > > > > Second, if you are serious about getting this included in
> > > > > Django I'd file a bug and upload a patch, it's much easier to discuss
> > > > > these things when there's something concrete on the table.
> > > > > Alex
> > > > > --
> > > > > "I disapprove of what you say, but I will defend to the death your
> > > > > right to say it." -- Voltaire
> > > > > "The people's good is the highest law." -- Cicero
> > > > > "Code can always be simpler than you think, but never as simple as you
> > > > > want" -- Me
|
