Idea: easy way to extend / override UrlNode model

[bashu]

Similar to django.contrib.auth, I am talking about AUTH_USER_MODEL setting

[bashu]

What do you think about https://github.com/wq/django-swappable-models or less dependencies is better?

[bashu]

or mezzanine approach http://blog.jupo.org/2011/11/10/django-model-field-injection/

[vdboor]

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:

• doesn't affect migrations (how are people going to custom ship UrlNode migrations?)
• doesn't have to manually alter things, like swapper now needs.
• doesn't require having to create a custom base model if you want an extra field available everywhere.

For example:

• Add a "Facebook Image" field to all pages.
• Add a "section color" setting to all pages.

If this can be configured per class, that would be really useful. e.g. something like:

FLUENT_PAGES_CUSTOM_FIELDS = {
  'Page': {
    'fields': {
        ...
     },
  },
'RedirectNode': {
  'fields': (
     ...
  ),
}
}

[mrmachine]

django-appdata sounds interesting, but it might not be well suited to many use cases as it stores serialised data in a text field making it difficult or impossible to filter via the ORM (unless I'm missing something?)

Perhaps something similar to TranslatableModel, that allowed fields to be registered separately instead of being declared on the model itself, and still allowed them to be filtered via the ORM, or is that no better than just using MTI?

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?

[vdboor]

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. status and publication_date are mainly used in the .published() logic. There aren't that many fields on UrlNode, so I don't think you'd ever want to remove more. Anything else such as in_sitemaps or in_navigation could easily be ignored.

[mrmachine]

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 django-publish, but without having to extend from an abstract model and add fields to your own models. I don't have anything concrete yet, but I was thinking about linking the publication data to objects via django-generic-m2m or regular GFKs and maybe even using django-polymorphic to make the publication model extensible.

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 django-fluent-* family also provided a decoupled publishing app that could be used with pages or any other model, much like django-fluent-contents. Is that something you'd be interested in?