Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Idea: easy way to extend / override UrlNode model #67
or mezzanine approach http://blog.jupo.org/2011/11/10/django-model-field-injection/
Hi! Good questions!
I really love the mezzanine approach, where you can configure custom fields on a model. Afaik, they even packaged that into django-appdata, and that's something I'd love to get integrated. It's on my wishlist for a long time.
The major benefits I see are:
If this can be configured per class, that would be really useful. e.g. something like:
Perhaps something similar to
I too would like to customise UrlNode, but I would like to remove fields. UrlNode already has status and publication date fields, but I'd like to use a different publishing workflow where UrlNode objects are not the only objects being published.
Refactoring the status and publication fields out into a separate abstract model and using swapper might be easier in this case. Is that something that you would also consider? Or are status and publication date absolutely required for fluent-pages to work?
You're correct about django-appdata; that could mainly be used for nice "add on" properties, that don't require querying. Unless someone builds that on top of a PostgreSQL JSON or HStore field, you can't query that. It's for stuff that is "meta data", like extra SEO fields, a theme color or different header-background image. Hardly stuff you'd query for.
The disadvantage of attaching yet another model is getting an "3 queries per page" issue, but with some caching combined that might be a really good idea.
I'm curious about your publishing workflow. Is it something we can adopt to the core, or is it some domain-specific idea? After seeing stand-alone Django apps for publishing (e.g. django-publish) it makes sense to have this in a stand-alone app. After all, pages aren't the only objects that need a workflow; blog entries and your custom models equally could benefit from that.
The fields of UrlNode are currently based on what I've considered to be a minimum shared set of fields, that allow easy filtering and inclusion in a menu.
For publishing, it's like you said. Pages aren't the only objects that need to be published. I want to decouple the publication status from any one particular model, and allow any object to become publishable. I want to allow a different set of users to manage publication vs content creation.
So I was thinking of an app like
I'd like the users who are responsible for publication to be able to log in and see a list of all objects that are in draft status, and then be able to review and publish easily, without having to go into each app where content is being created.
It would be great if the