Following this article on polymorphism, I decied to use the semi-structured-model for my blog posts. The reason is that I just don’t know what kind of blog post types we are gonna need in the future. I want all the blog post to be of the same model type to keep sorting, displaying, etc… simple. However, I want the articles to have different structures. So there will be a simple post with no headline, a post containing of headline and textbody and there will be posts that also have media files attached.
In the django admin the json field should not be displayed. I don’t want users to have to write posts as JSON code. Instead I want a mask for each type of blog post. I found a useful package for that. Here is an example of the package in use to display a json field.
- If you have any suggestions or criticism for my design choices, please let me know.
I’d like to offer a different perspective on this.
This is not intended to be either a suggestion or a criticism of your current design choice, as I believe this is one of those situations where there’s no absolute “right” answer. But, I believe there are different ways to solve this.
In this type of situation, I’d be inclined to use something like Markdown or reStructuredText for the blog posts. This allows for the ability to include aspects of the post such as a headline or attached media files, or even extend the language for the implementation of extensions for other currently-unforseen requirements without breaking them out into other fields.
I’m basically looking at this as saying there is only one entity here - a “blog post”, and all the variations are just the presence or absence of attributes associated with that blog post that don’t rise to the level of being a different type of object.
Markdown and reStructuredText are great tips. I think I will want to include a functionality like that later on.
I agree with all of that and I have only one blog post implemented. I’m struggling with the old problem of providing several forms for the same model in the admin again. There are several usecases with certain sets of attributes, I want different forms for them. Let me give two examples.:
“Release of a track”-post
Attributes would be a headline. The headline would be a fixed caption provided by the system, not the user. There would however be room for some text talking about the release. This text would be generated by the user. Finally, the track would be selected. There is no need for markup to place the track within the post as there is already a predefined template for such posts.
The form would basically have a field for the text and a field for selecting the track. And that’s it.
Full Blown blog post
There would be a field for the headline, a field for the actual text, I want to implement functionality for adding media items that can be placed within the text by the user and so on.
For this I come back to the general principle that the admin is not supposed to be your primary UI. That’s not how it’s designed and it’s not what it’s intended usage is. If you’ve got different people using this on a consistent basis, when you need this type of flexibility, you’re going to find it a lot easier in the long run to put together different views.