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.
- What is the proper way to handle having different types of blog posts? I was gonna add a field to the blog post model that defines the post type. But how do I differentiate it in the admin? For editing, I can use the blog post type field to load the proper editor. However when creating a new post, I would need to differentiate it. I’m thinking of resorting to javascript for this and add some kind of selector which will then determine what the JSON-editor looks like. Is that ok or is there a better way?
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.
So despite the fact that the same instance of a model would be created, very different forms need to be displayed. I originally played around with creating formsets from the JSON-field. But going down that road I really have to bent the admin and it feels like I would have to write a lightweight version of djangos form handling classes. The amount of work doesn’t seem justified. Using Javascript to create a form from the JSON-field in the way that the linked package does seems reasonable. I usually shy away from Javascript, I prefer to do as much on the server side as possible but it seems jsutified in this case. And then I could just add a little Javscript functionality for displaying the proper form configuration.
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.