1

Question Context

I am responsible to design the cms architecture for a project.

The requirements state that a group of editors should be able to create "Projects".

Each project..

  • saves meta data about itself
  • is queryable from other places (e.g. top 5 projects).
  • has a page that displays information about it. (does not need to be a cms page instance)
  • can be connected to countries (meaning that an implementation of that project exists in the selected counties).
  • can have sub-pages which in turn can also be nested.

Imagined Example

Using the django-cms documentation as a bases I would image the resulting structure to look like this:

  • Projects (apphook)
    • "Project 1" (Page for project 1 model instance)
    • "Project 2" (Page for project 2 model instance)
      • "Project 2 Subpage 1" (Subpage for project 2 model instance)
      • "Project 2 Subpage 2" (Subpage for project 2 model instance)
        • "Project 2 Sub-Subpage" (Subpage of "Project 2 Subpage 2")

However that does not seem to exist or at least I did not see any references on how to get such a structure.

In a video I heard that as soon as there is an apphook.. subpages do not make sense anymore. Somewhere else I read that in theory if the hook is permissive enough.. it could be combined. However even if that works.. the subpages would not be liked to actual instances of the custom apphook model.

PS: I am currently using: django-cms==3.3.0

Question

How can I feature such a structure using django-cms?

I figured it could be done by having an apphooked page for each project. In that case.. the server would have to be restarted for every newly created project. That does not seem to be very elegant.

Alternatives

I have been working with wagtail on a previous project. Thus I do know how to implement such a structure with wagtail easily using ProjectPage and ProjectSubpage models. I refuse to give up on django-cms being capable of replicating such functionality. I am open for alternative paradigms and approaches. Maybe there are some I have not thought of. If so please let me know. :)

Request

Guidance and ideas are very welcome! Please tell me if you know of any way how to get that or have some idea that could point me in the right direction.

Thank you!

Brett
  • 4,341
  • 2
  • 19
  • 17
Eraldo
  • 535
  • 8
  • 17
  • A simple approach would be to create a 'Project Plugin' (and eventually a special template). – ohrstrom Jun 16 '16 at 11:54
  • Hey ohrstrom, thank you for engaging. How would a 'Project Plugin' solve the issue at hand? – Eraldo Jun 16 '16 at 12:40
  • Not sure if it conflicts with any of your requirements. But it would allow you to completely structure the site content through the CMS tree including all sub pages. Then you would just add corresponding "Project Plugins" on your "Project x" level. However - there are some shortcomings with that approach, like having to handle the page tree 'manually' (instead of building it out of the project data). – ohrstrom Jun 16 '16 at 13:20
  • Yeah I see multiple caveats with that approach. Also the data is spread across multiple plugins.. that is not particularly nice. Plus the management of projects seems inconsistent: There could be project pages without actual project instances. There could also be projects without pages associated to them. (like when creating a project page.. setting up a project plugin then deleting that page) Just to name a few. That seems quite hacky to me. I am wondering if there is a clean solution as well. Can you understand what I mean @ohrstrom? – Eraldo Jun 16 '16 at 14:22
  • Yes I completely understand. So then you likely will have to take the apphook way. Create *one* apphook, create a 'project sub-page' model that can be attached to projects and use `cms placeholders` in that model. So you have the both the benefits from a 'real' project database and the comfortable CMS editing in the frontend. Use `cms menus` to build the navigation tree and `cms toolbars` so that editors can create/handle project sub-pages. – ohrstrom Jun 16 '16 at 14:39
  • Better. The down side: I have to replicate the already existing features of cms pages for the custom `sub-page` model. While they do actually have identical requirements like reordering, publishing, translations, etc. Something like a PagePlaceholder that hooks into the cms would be awesome. Even cleaner: I like the approach wagtail uses: Having different Page models instead of one extension for all of them. I am aware that it sounds like I want the best of both worlds. :) Thank you for pointing out your solution idea @ohrstrom. While not being content with it -- It is currently my favourite. – Eraldo Jun 16 '16 at 15:31
  • Let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/114861/discussion-between-ohrstrom-and-eraldo). – ohrstrom Jun 16 '16 at 15:33

1 Answers1

1

A couple of points here for you.

  1. django CMS can happily serve pages "beneath" and apphook, but the apphook gets priority during URL resolution. So, just make sure that your apphook's URL patterns don't gobble up everything and sub-pages should be OK.

  2. An alternative approach would be to make a one-to-many table that holds "page-like" attributes (title, meta-attributes, etc.) and at least one PlaceholderField. This can then be used to present what appears to be normal CMS pages that the apphook-itself can control with its views. So, you could have apphook-model-specific context and url-patterns and still have almost all of the front-end editing features of the CMS.

I hope this helps!

mkoistinen
  • 7,724
  • 3
  • 41
  • 56