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

[Tim Graham]

The introduction to the admin in the docs [0] reads:

"One of the most powerful parts of Django is the automatic admin interface. It reads metadata in your model to provide a powerful and production-ready interface that content producers can immediately use to start adding content to the site."

I've proposed [1] changing it to:

"One of the most powerful parts of Django is the automatic admin interface. It reads metadata from your models to provide a quick and rudimentary interface where trusted users can manage content on your site.

The admin has many hooks for customization but beware of trying to use those hooks exclusively. If your needs outgrow what the admin provides, it may be simpler to write your own views. The admin’s recommended use is as an organization’s internal management tool. It’s not intended for building your entire front end around."

However several reviewers have made comments like "I worry that the description of the Admin sells it short. The Admin is actually brilliant kit and works as advertised." and "Downgrading Django's admin from "powerful and production ready" to "quick and dirty [old wording]" is very harsh... And I fear this will not only lower user's expectations, but also dev's carefulness!"

I think part of the reason I raise this is that I'm getting weary of adding hook after hook for customizing every little thing. I worry we'll end up with an unmaintainable mess at some point. The latest proposal that has me thinking about this adds ModelAdmin.orderable_by and ModelAdmin.get_orderable_by() for the use case of disabling sorting of a column in the change list [2]. This topic also came up in the discussion of whether or not to add ModelAdmin.exclude and ModelAdmin.get_exclude() [3] (which hasn't been done yet). There's also an open question about whether or not to add a view permission [4]. I don't want to discuss each of these decisions on this thread but rather the broader question of whether putting a lot of effort in this area is a direction we should pursue. I know there have been some proposals of "admin2" but realistically I think the admin has too many customizations points such that superseding it with something new and innovative won't be feasible from a backwards compatibility standpoint.

[0] https://docs.djangoproject.com/en/dev/ref/contrib/admin/
[1] https://github.com/django/django/pull/6104
[2] https://github.com/django/django/pull/6107
[3] https://groups.google.com/d/topic/django-developers/WrnhmTyLHuY/discussion
[4] https://groups.google.com/d/topic/django-developers/X7YEGB9KJNc/discussion

[Russell Keith-Magee]

On Wed, Feb 10, 2016 at 7:25 AM, Tim Graham <timog...@gmail.com> wrote:

The introduction to the admin in the docs [0] reads:

"One of the most powerful parts of Django is the automatic admin interface. It reads metadata in your model to provide a powerful and production-ready interface that content producers can immediately use to start adding content to the site."

I've proposed [1] changing it to:

"One of the most powerful parts of Django is the automatic admin interface. It reads metadata from your models to provide a quick and rudimentary interface where trusted users can manage content on your site.

The admin has many hooks for customization but beware of trying to use those hooks exclusively. If your needs outgrow what the admin provides, it may be simpler to write your own views. The admin’s recommended use is as an organization’s internal management tool. It’s not intended for building your entire front end around."

However several reviewers have made comments like "I worry that the description of the Admin sells it short. The Admin is actually brilliant kit and works as advertised." and "Downgrading Django's admin from "powerful and production ready" to "quick and dirty [old wording]" is very harsh... And I fear this will not only lower user's expectations, but also dev's carefulness!"

I think part of the reason I raise this is that I'm getting weary of adding hook after hook for customizing every little thing. I worry we'll end up with an unmaintainable mess at some point.

“At some point”? Yes… some point long ago :-)

 

The latest proposal that has me thinking about this adds ModelAdmin.orderable_by and ModelAdmin.get_orderable_by() for the use case of disabling sorting of a column in the change list [2]. This topic also came up in the discussion of whether or not to add ModelAdmin.exclude and ModelAdmin.get_exclude() [3] (which hasn't been done yet). There's also an open question about whether or not to add a view permission [4]. I don't want to discuss each of these decisions on this thread but rather the broader question of whether putting a lot of effort in this area is a direction we should pursue. I know there have been some proposals of "admin2" but realistically I think the admin has too many customizations points such that superseding it with something new and innovative won't be feasible from a backwards compatibility standpoint.

For me, it depends on how much time and energy you’re spending on these enhancements.

I agree that a new admin is needed, and at this point, it’s highly unlikely that it will be backwards compatible. The best we could hope for is a solid migration guide, or maybe some sort of compatibility shim.

However, in the meantime, for better or worse, we have an admin, and people are using it. If there’s a feature someone wants to add, and they’re sufficiently motivated to develop a patch, and that patch doesn’t make things *worse* (i.e., it’s a well designed feature that doesn’t cause problems), and the review process isn’t excessively onerous (i.e., you’re not having to spend multiple hours reviewing and re-reviewing a patch to make it trunk ready) then I we should accept the patch. 

Yours,

Russ Magee %-)

 

[Riccardo Magliocchetti]

Hello,

Il 10/02/2016 00:25, Tim Graham ha scritto:
> The introduction to the admin in the docs [0] reads:
>
> "One of the most powerful parts of Django is the automatic admin interface.
> It reads metadata in your model to provide a powerful and production-ready
> interface that content producers can immediately use to start adding content
> to the site."
>
>
> I've proposed [1] changing it to:
>
> "One of the most powerful parts of Django is the automatic admin interface.
> It reads metadata from your models to provide a quick and rudimentary
> interface where trusted users can manage content on your site.

s/rudimentary/basic/ maybe? As a non native english speaker rudimentary does not
sound positive.

>
> The admin has many hooks for customization but beware of trying to use those
> hooks exclusively. If your needs outgrow what the admin provides, it may be
> simpler to write your own views. The admin’s recommended use is as an
> organization’s internal management tool. It’s not intended for building your
> entire front end around."

To me that the intended use of the admin as internal management tools has been
kinda obvious given it's accessible to user flagged as staff.

[snip]

> I know there have been some proposals of "admin2" but realistically I think the
> admin has too many customizations points such that superseding it with something
> new and innovative won't be feasible from a backwards compatibility standpoint.

Wasn't the plan to revise these customizations points and thus probably breaking
backwards compatibility anyway?


--
Riccardo Magliocchetti
@rmistaken

http://menodizero.it

[Dheerendra Rathor]

On Tue, 9 Feb 2016 at 23:25 Tim Graham <timog...@gmail.com> wrote:

The introduction to the admin in the docs [0] reads:

"One of the most powerful parts of Django is the automatic admin interface. It reads metadata in your model to provide a powerful and production-ready interface that content producers can immediately use to start adding content to the site."

I've proposed [1] changing it to:

"One of the most powerful parts of Django is the automatic admin interface. It reads metadata from your models to provide a quick and rudimentary interface where trusted users can manage content on your site.

How about quick and powerful?  

The admin has many hooks for customization but beware of trying to use those hooks exclusively. If your needs outgrow what the admin provides, it may be simpler to write your own views. The admin’s recommended use is as an organization’s internal management tool. It’s not intended for building your entire front end around."

What I have understood from using admin for years is that customizing admin is really tough for new users, but for power users admin is a really handy tool. I've written way complex user permission handling using admin tool which could have given a hard time if written in normal django views.

 

However several reviewers have made comments like "I worry that the description of the Admin sells it short. The Admin is actually brilliant kit and works as advertised." and "Downgrading Django's admin from "powerful and production ready" to "quick and dirty [old wording]" is very harsh... And I fear this will not only lower user's expectations, but also dev's carefulness!"

I think part of the reason I raise this is that I'm getting weary of adding hook after hook for customizing every little thing. I worry we'll end up with an unmaintainable mess at some point. The latest proposal that has me thinking about this adds ModelAdmin.orderable_by and ModelAdmin.get_orderable_by() for the use case of disabling sorting of a column in the change list [2]. This topic also came up in the discussion of whether or not to add ModelAdmin.exclude and ModelAdmin.get_exclude() [3] (which hasn't been done yet). There's also an open question about whether or not to add a view permission [4]. I don't want to discuss each of these decisions on this thread but rather the broader question of whether putting a lot of effort in this area is a direction we should pursue. I know there have been some proposals of "admin2" but realistically I think the admin has too many customizations points such that superseding it with something new and innovative won't be feasible from a backwards compatibility standpoint.

Yes admin do provide customization for every little thing. IMHO, the power of admin lies in this. A new admin might work but I fear power users won't like it if it does not provide all those little customization like current admin.  

[0] https://docs.djangoproject.com/en/dev/ref/contrib/admin/
[1] https://github.com/django/django/pull/6104
[2] https://github.com/django/django/pull/6107
[3] https://groups.google.com/d/topic/django-developers/WrnhmTyLHuY/discussion
[4] https://groups.google.com/d/topic/django-developers/X7YEGB9KJNc/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-develop...@googlegroups.com.
To post to this group, send email to django-d...@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/72ecc667-1dba-432e-a749-dca214fa77b5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Andy Baker]

I can't help but feel that the "admin is very rudimentary and hard to customize" is perpetually overplayed by many in the community. Maybe I'm suffering Stockholm Syndrome but I'd like to raise a dissenting voice.

I find it the quickest and most efficient way to provide an admin interface for staff users. It's remarkably easy to customize in my view (and I've done a heck of a lot of it). If it didn't exist I'd have to invent something damn similar. :)

More importantly - it's not an either/or decision. I always recommend starting with the admin - use the available hooks and means of customization and when you really, truely hit a brick wall - then remember "It's just Django" - drop down to a custom view that uses the admin base templates and CSS and easily integrates with other admin pages. The beauty of this is that you can carry on using the admin for everything else where it still provides easy wins.

Warning people away means they are less likely to discover the many simple customization hooks and they are more likely to spend time reinventing the wheel.

If the admin was truly as limited as some make it out to be, then one of the many attempts to replace it would have gained momentum. I'm not saying it couldn't be replaced with something better - but it's far from being something we should cover in warnings and caveats.

Sigh. I perpetually intend to write tutorials to help demystify admin customization - but I've sadly perpetually failed to find the time...

[Andy Baker]

Just to follow up - I think the biggest improvements I've yearned for are fairly simple and unlikely to break backwards compatibility:

1. Break up the remaining monolithic methods to allow easier overriding (this is much better nowadays but a few beasts remain)

2. More blocks in the templates or more includes - again to allow overriding. 

Also - If those parts of the admin that are unique to it and not merely aspects of ModelForms, CBVs and other generic Django features  could be broken out and made re-susable - then over time the admin could become simply an example of how more general Django features can be glued together. 

[Dheerendra Rathor]

On Wed, 10 Feb 2016 at 13:55 Andy Baker <and...@gmail.com> wrote:

I can't help but feel that the "admin is very rudimentary and hard to customize" is perpetually overplayed by many in the community. Maybe I'm suffering Stockholm Syndrome but I'd like to raise a dissenting voice.

I find it the quickest and most efficient way to provide an admin interface for staff users. It's remarkably easy to customize in my view (and I've done a heck of a lot of it). If it didn't exist I'd have to invent something damn similar. :)

More importantly - it's not an either/or decision. I always recommend starting with the admin - use the available hooks and means of customization and when you really, truely hit a brick wall - then remember "It's just Django" - drop down to a custom view that uses the admin base templates and CSS and easily integrates with other admin pages. The beauty of this is that you can carry on using the admin for everything else where it still provides easy wins.

Warning people away means they are less likely to discover the many simple customization hooks and they are more likely to spend time reinventing the wheel.

If the admin was truly as limited as some make it out to be, then one of the many attempts to replace it would have gained momentum. I'm not saying it couldn't be replaced with something better - but it's far from being something we should cover in warnings and caveats.

Sigh. I perpetually intend to write tutorials to help demystify admin customization - but I've sadly perpetually failed to find the time...

It comes to my  mind many times to create a video tutorial for advance Django including customizing admin and other advance part of Django like complex querysets (with F, Q etc). 

We can work together on this to create nice tutorials. 

On Tuesday, 9 February 2016 23:25:20 UTC, Tim Graham wrote:

The introduction to the admin in the docs [0] reads:

"One of the most powerful parts of Django is the automatic admin interface. It reads metadata in your model to provide a powerful and production-ready interface that content producers can immediately use to start adding content to the site."

I've proposed [1] changing it to:

"One of the most powerful parts of Django is the automatic admin interface. It reads metadata from your models to provide a quick and rudimentary interface where trusted users can manage content on your site.

The admin has many hooks for customization but beware of trying to use those hooks exclusively. If your needs outgrow what the admin provides, it may be simpler to write your own views. The admin’s recommended use is as an organization’s internal management tool. It’s not intended for building your entire front end around."

However several reviewers have made comments like "I worry that the description of the Admin sells it short. The Admin is actually brilliant kit and works as advertised." and "Downgrading Django's admin from "powerful and production ready" to "quick and dirty [old wording]" is very harsh... And I fear this will not only lower user's expectations, but also dev's carefulness!"

I think part of the reason I raise this is that I'm getting weary of adding hook after hook for customizing every little thing. I worry we'll end up with an unmaintainable mess at some point. The latest proposal that has me thinking about this adds ModelAdmin.orderable_by and ModelAdmin.get_orderable_by() for the use case of disabling sorting of a column in the change list [2]. This topic also came up in the discussion of whether or not to add ModelAdmin.exclude and ModelAdmin.get_exclude() [3] (which hasn't been done yet). There's also an open question about whether or not to add a view permission [4]. I don't want to discuss each of these decisions on this thread but rather the broader question of whether putting a lot of effort in this area is a direction we should pursue. I know there have been some proposals of "admin2" but realistically I think the admin has too many customizations points such that superseding it with something new and innovative won't be feasible from a backwards compatibility standpoint.

[0] https://docs.djangoproject.com/en/dev/ref/contrib/admin/
[1] https://github.com/django/django/pull/6104
[2] https://github.com/django/django/pull/6107
[3] https://groups.google.com/d/topic/django-developers/WrnhmTyLHuY/discussion
[4] https://groups.google.com/d/topic/django-developers/X7YEGB9KJNc/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-develop...@googlegroups.com.
To post to this group, send email to django-d...@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/26f81439-3648-40cf-9a46-fceb5ccabba1%40googlegroups.com.

[Curtis Maloney]

On 11/02/16 00:55, Andy Baker wrote:
> I can't help but feel that the "admin is very rudimentary and hard to
> customize" is perpetually overplayed by many in the community. Maybe I'm
> suffering Stockholm Syndrome but I'd like to raise a dissenting voice.

I must admit I'm a large proponent of warning against getting caught up
in "Admin as my management console".

As customisable as it can be, I find the problem to be it is a
data-centric view of your system, closely tied to the database models.

IMHO a management interface for site should be a _process_ centric view,
abstracting away the implementation details of tables and fields.

Perhaps a better way to think of it as the difference between a
"management" and a "maintenance" interface.

True, in a lot of cases these can be the same thing, and for simpler
sites Admin works "just fine". However, I've been on too many projects
that wind up spending a lot of time and effort customising Admin to do
things that would have been simpler in a custom view.

Worse still, I've seen projects alter their schema design to accommodate
Admin's limitations [like lack of nested inlines]

Is it possible to add other views to admin? Sure... though it's not
clear, or well documented.

Can documentation alone overcome this problem? I'm not convinced it can.

For some years now I've been proposing an investigation into slicing
Admin into two layers: a base "management interface framework" layer,
and "admin" built atop this framework.

Then we can keep providing the Admin we all know and love, and also make
it easier for people to build their own management interfaces.

However, I don't currently have the time [or admin familiarity] to
undertake this work.

--
Curtis

[Andy Baker]

> As customisable as it can be, I find the problem to be it is a data-centric view of your system, closely tied to the database models. 

You're correct that a truly 'task-centric' UI would be a lot of effort - but really - how common are such interfaces in their fullest sense? In reality nearly every admin UI is a fairly clear mirror of the underlying data schema. Show me a web app and I've got a fairly good chance of predicting the db tables.

I suspect that what is much more common is the ability to have 'cross-cutting concerns' - i.e. actions that involved and orchestrate changes over multiple tables. There are many places that you can enable such things without needing to twist the admin too far out of shape: usertools, admin actions, custom changelist columns etc etc.

I'm not claiming any of this results in the 'perfect ui' and given the budget - yes - a ground-up custom admin would probably be superior. But real-life projects are nearly always budget constrained - especially away from the public-facing side - and quite frankly - the Django admin has enabled me to complete projects that would have been financially impossible to develop without it.

> Perhaps a better way to think of it as the difference between a "management" and a "maintenance" interface. 

I'm not sure I am clear on the distinction you are making here.

> True, in a lot of cases these can be the same thing, and for simpler sites Admin works "just fine".  However, I've been on too many projects that wind up spending a lot of time and effort customising Admin to do things that would have been simpler in a custom view. 

This comes back to my point that it's not a binary choice. The admin+customization gets you 80% of the way there quickly. When you find something that doesn't fit nicely just add a line to urls.py and a {% extends "admin/base_site.html" %} to the top of your template and you've got the full power of Django to solve that one particular piece of the problem.

> Is it possible to add other views to admin?  Sure... though it's not clear, or well documented. 

I would argue that it's also fairly clear as it's mostly "just django". At its simplest an admin view is just a Django view that uses the admin base template. What's unclear about that? How to incorporate linkage between the admin-proper and custom views is fairly simple but maybe not immediately obvious to a beginner. The various hooks for this are fairly well documented although the documentation is scattered through various places on this rather monolithic page: https://docs.djangoproject.com/en/1.9/ref/contrib/admin/

A single 'common ways to customize the admin' page could go a long way to helping here.

[bliy...@rentlytics.com]

While I think it's true that a process centric workflow (wizards, or hubs anyone?) would be incredibly useful, that does not take away from the fact that the model centric admins are also incredibly useful, and time saving.  It's so easy to add search, sorting, bulk actions, etc to an admin--these are things I've often spent days or weeks working on in other systems.  With django it is often a matter of minutes to add these incredibly common features.  This is probably one of my favorite things about the django framework.

[Chris Foresman]

FWIW, we used to tell clients that Django offers a basic admin interface "for free". However, we NEVER had a client that was sufficiently familiar with what a database is or how data modeling works for this to ever suffice. The first thing we always do on new project is immediately disable the admin and simply design APIs that allow our front-end teams to build some kind of custom dashboard/admin interface.

IME, the admin is "sufficient" for sysadmins or technically experienced users, but in practice those are few and far between.

[Curtis Maloney]

On 11/02/16 20:11, Andy Baker wrote:
> > As customisable as it can be, I find the problem to be it is
> a data-centric view of your system, closely tied to the database models.
>
> You're correct that a truly 'task-centric' UI would be a lot of effort -
> but really - how common are such interfaces in their fullest sense? In
> reality nearly every admin UI is a fairly clear mirror of the underlying
> data schema. Show me a web app and I've got a fairly good chance of
> predicting the db tables.

I think this is a matter of scale... for many small to medium scale
apps, you can run close to the schema. But for some of the large
projects I've worked on, we really needed to hide a lot of complexity
from the users.

> I suspect that what is much more common is the ability to have
> 'cross-cutting concerns' - i.e. actions that involved and orchestrate
> changes over multiple tables. There are many places that you can enable
> such things without needing to twist the admin too far out of shape:
> usertools, admin actions, custom changelist columns etc etc.

I absolutely agree with this. Again, for the cases where admin fits, it
works well. But going beyond that, there's not a lot of clarity in how
to fit in with it.

> I'm not claiming any of this results in the 'perfect ui' and given the
> budget - yes - a ground-up custom admin would probably be superior. But
> real-life projects are nearly always budget constrained - especially
> away from the public-facing side - and quite frankly - the Django admin
> has enabled me to complete projects that would have been financially
> impossible to develop without it.

Unfortunately, what I've seen time and again is when people finally hit
the wall in admin customisation, they're too invested in admin to go any
other path. So I always advise caution in this - make sure people go in
with "eyes open".

> > Is it possible to add other views to admin? Sure... though it's
> not clear, or well documented.
>
> I would argue that it's also fairly clear as it's mostly "just django".
> At its simplest an admin view is just a Django view that uses the admin
> base template. What's unclear about that? How to incorporate linkage
> between the admin-proper and custom views is fairly simple but maybe not
> immediately obvious to a beginner. The various hooks for this are fairly
> well documented although the documentation is scattered through various
> places on this rather monolithic
> page: https://docs.djangoproject.com/en/1.9/ref/contrib/admin/

Well, part of the problem is, I believe, that admin is structured very
differently to almost every other part of Django. It follows that has
been called a "publisher" pattern, where all related views, etc, for a
given resource are provided in a single class (more or less).

This monolithic nature is quite different to the "collection of views in
a module" approach used elsewhere.

I'm not saying this is wrong, but it does mean you have to learn a whole
new approach in order to work with it on anything beyond a superficial
level.

> A single 'common ways to customize the admin' page could go a long way
> to helping here.

+1

--
Curtis

[Andy Baker]

> However, we NEVER had a client that was sufficiently familiar with what a database is or how data modeling works for this to ever suffice. 

I've got more than two dozen non-technical clients happily using the admin. They also have no familiarity with data modelling but I'm not quite sure how that would help or hinder them. The concept of a filterable list view and an editable form luckily doesn't require discussing 4th normal form or the benefits of relational algebra ;-)

[Tim Graham]

Here's another try for the docs:

One of the most powerful parts of Django is the automatic admin interface. It

reads metadata from your models to provide a quick, model-centric interface
where trusted users can manage content on your site. The admin's recommended
use is limited to an organization's internal management tool. It's not intended

for building your entire front end around.

The admin has many hooks for customization, but beware of trying to use those
hooks exclusively. If you need to provide a more process-centric interface
that abstracts away the implementation details of database tables and fields,
then it's probably time to write your own views.

[Marc Tamlyn]

That looks like a good balanced message to me.

--

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-develop...@googlegroups.com.
To post to this group, send email to django-d...@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/363c6710-b75f-40d5-a790-f0ab98aa5635%40googlegroups.com.

[Aymeric Augustin]

+1

-- 

Aymeric.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMwjO1Gku272bs0uUOqsTV7jAYX_4cPHqdKhoVyCcQZEuW4Mag%40mail.gmail.com.

[Ramez Ashraf]

Like what is "site front end" that the admin shouldn't replace ?!
I work with business application where clients puts data in and get reports back... (Like Sales/Store/Client balances and stuff)
I tried to work "my front end" (after getting the bad/wrong message from the docs) but it was so much time and mess and so much like re-inventing the wheel really.

The admin have lots of capabilities that does not yet exist in any other parts or CBV
To name a few:
1. Inlines  (FormView is like a teenager playing in the park next to Spartan Hero)
2. Entry Log change message 
3. Various 3rd party support (ex: django-reversion)
4. Changelist filters / search / table sort
5. Change form (save,save and continue, save and add another)

6. Delete confirmation displaying related objects that will get deleted along (though sometimes big and heavy)
.. the list can easily get much bigger.

And now with custom admin sites, we can get rid of the is_staff check, get rid of unrelated 3rd party app registered models (which might be only visible to staff indeed), override the templates and have a completely new look .

I think the admin should be seen as the "Best django-inc" way to manipulate data to your database, and get advertised as such.
Not "intended to use by only management", but to anyone with access to add/change/delete to a model.

IMHO, If there is some enhancement to do for the admin.. i think this should be it, along with more documentation/ how-to's & examples.

Thank you and kind regards

[James Pic]

On Tue, Mar 15, 2016 at 1:59 AM, Ramez Ashraf <ramez...@gmail.com> 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