This is a request for help from all the Django users out there, it’s about using different templates for different types of article in a blog or CMS system

There’s a project I’m working on that I think could really benefit from switching to Django primarily due to its powerful admin system, but there are some requirements that i’m not sure can easily be solved. I can think of ways to solve it using a hand-coded admin system but that removes the main benefit of making an immediate switch.

The Problem

The system requires that different types of content be deployed regularly using a number of significantly different templates. They are different to the extent that an admin panel for adding content would have different form fields for each template, i.e. some templates might just use one textarea whilst others might use a number of text areas and some text fields and image selection fields. Can this kind of thing be done easily (or with an acceptable level of difficulty) using Django and ideally within the auto-admin itself?

If I were to try and solve this problem in another programming language or without using the Django admin I would do it as follows:

• A folder would contain all the templates as html files
• Editable regions for each template would be defined using some kind of commenting syntax that would allow preview content to be shown if the template was loaded in a browser
• The system would parse the template when it’s requested and generate a form based on the properties of each editable region
• When the content is saved the form content would be converted to a map of labels to content and stored to a single field in a database table

• When the page is rendered that data would be retrieved, parsed and inserted into the page, replacing all the comments with real content.

  The reason editable regions have to be defined is that the templates are quite complex and we don’t want people accidentally breaking stuff by forcing them to work with the template html.

  I’m open for suggestions on better ways to approach this problem, both for non-Django and Django usage (since even if we solve it for Django we’d need a way to do basically the same thing in non-Django apps)