I ♥ Panels (it does the simple layout on this blog, but it’s capable of much more advanced usage). The genius of panels is that it replaces the site-centric content-management workflow in Drupal with a view-centric one, where the manager can place subviews, add contexts (which may draw their argument from the URL, etc, and may provide new subviews for placement), and change the layout on a per-view basis, without having to delve into the central admin pages.
I want to develop something like this for Django/WSGI, but I can’t just copy the architecture of panels since it is uniquely tuned to the shortcomings and features of Drupal. This post is a work-in-progress design document for a new “helper” API for Django and hopefully also WSGI, which will allow view developers to wrap existing views to enable runtime layout management.
key concepts
Contexts are values provided to the panel, which will usually be instances of a given model or queryset, but could be anything. Contexts may be:
- passed in by the view which is implementing the panel
- provided globally (ie, current user)
- added at runtime (ie, a fixed model instance)
Subviews (name subject to change) are placeable “bare” views which provide some output driven by one or more contexts. Examples of subviews:
- model-specific views included with the application
- generic list view
- generic detail view
- generic edit view
Layouts are probably just templates, with a special {% region “name” %} template tag to specify the regions. It’s probably not a good idea to reuse the block template tag, since this might cause some conflicts.
On the runtime side, the content manager can click an “edit” link to access the layout/context manager. Here she can add contexts, change the layout, and place subviews.
That’s the basic idea, but many details are still missing.