I just found out today that you cannot stack an inline admin in another inline admin.
Here’s what I’m trying to do: I have textobjects and I want them to be multilingual. So let’s say there is a Textbody. It lives in contentmanager.models. The textbody model has no actual text. The actual text lives in multitext.models as Body. It has a foreign key relationship to Textbody, it has the actual text and a language. So you can for instance have a Textbody with an english and a italian Body. I use an InlineAdminModel to display them both and it works just fine. However, a textbody needs a context to live in.
In comes the top level app, it’s called eulogymanager. The eulogymanager manages eulogies (duh), and they have Textbodies. So I gave Textbodies a ForeignKeyField to Eulogy. I created an InlineModelAdmin for the both and ended up with an almost empty admin add page.
I tried out django-nested-admin and got it to work as I originally intended. However, I would like to better understand how I’m supposed to do it the Django way.
- Is it not intended to have such complex relationships between models in Django? Or am I making it unnecessarily complicated by bad desgin?
- My goal was to avoid writing my own forms and backend and use the Django Admin for everything. With some of the more complex models I have, I find it quite complicated to make the Django Admin work for me. Installing the additional package was something, I wanted to avoid but now I did it just to make the admin work. I’m thinking I might be better off just creating my own forms. I already spent a lot of time on django forms and the way I would do it is to just process the most inner child first, save it, get it’s key, pass that as the foreign key to the first parent, and so on untill I come out at the top. But ultimately I have no idea in which direction I should look, so a little guidance from someone with more experience would be well appreciated.
<opinion> No, it’s not that complex relationships are a problem with Django, or that it’s not intended for Django to support complex relationships. My take on it is that the admin is very specifically designed to support (effectively) one level of indirection on a page and that anything beyond that should be custom pages.
The admin is just a starting point, not an ending point - it’s something to get you up and running quickly. At any time when you hit the limits of the admin, it’s expected that you move on to custom forms and pages, and there are some cases where it’s very easy to hit those limits.
So yes, go ahead and start building your custom app to create your pages to fit your needs.
</opinion>
Ken
1 Like
Hey Ken,
thanks for the feedback. I have a theoretical education in programming but not a whole lot of reallife experience. I know the principles of objective programming, but applying them to Django, I sometimes hit walls and then I want to understand why exactly it’s happening. So understanding a method is easy, there’s usually documentation and examples. But there are more subtle principles that aren’t always easy to grasp.
I’ll try to give an example: in the language that I was originally educated in, more than one return statement was an utter taboo. But I think in Python it makes a lot of sense to ignore this principle. However, I was a bit surprised when I first stumbled on a method that had more than one return statement.
Anyways, I think I’ll let go of the idea to do everything with the django admin alone.
I’m familiar with the principle of “one return per method” - I’ve worked in environments where that was enforced during code reviews as a pragmatic requirement.
I’ve also work with code bases where that wasn’t enforced - and I’ll admit, I much prefer the former over the latter.
As a general rule, I always work to structure my code such that there’s only one return per method. When I encounter a situation where it appears that I might want to have more than one return, I generally look to see if I can break that method down into more than one method to eliminate that apparent need.
Ken