Replies: 12 comments
-
Hi @skirsdeda, Up to now I've been wary of going ahead with this change, because swappable image/document models have been quite a troublesome thing to maintain (for example, see #2881 where we've had to phase in a schema change across 3-4 releases to ensure that each migration is simple enough to be handled by Django's migration autodetector)... intuitively it seems that Page would throw up even more problems, being more complex and more central to Wagtail. I'm very encouraged to know that you've been able to make it work on django-filer, and I look forward to seeing your pull request! |
Beta Was this translation helpful? Give feedback.
-
@gasman, |
Beta Was this translation helpful? Give feedback.
-
This issue lead me to https://github.com/wq/django-swappable-models , it's a concept I didn't know until know, so thanks, and I put the link above in case it helps. |
Beta Was this translation helpful? Give feedback.
-
@skirsdeda Did you by change already had some time to look into this? Perhaps I can try to help with this? For our multi language module |
Beta Was this translation helpful? Give feedback.
-
@mikedingjan Not yet, unfortunately. But it should be pretty easy to get a working proof of concept. I mean most of it will be pretty mechanical work of replacing |
Beta Was this translation helpful? Give feedback.
-
True, however, providing the user with a good abstract Also the signals / receivers should be handled different |
Beta Was this translation helpful? Give feedback.
-
This would be a great help to make the implementation of |
Beta Was this translation helpful? Give feedback.
-
Is there still interest in moving this forward? @gasman I'd be really keen to hear your thoughts. |
Beta Was this translation helpful? Give feedback.
-
@sonnybaker, from cc: @DiogoMarques29 |
Beta Was this translation helpful? Give feedback.
-
@sonnybaker I'd be very keen to see this happen, but I'm too busy to work on it myself. Based on the experience of swappable images/docs, I expect it'll create extra maintenance work in future when dealing with migrations, but I think that's an acceptable tradeoff for the benefits (and perhaps the Page model is pretty stable by now and unlikely to need future migrations anyhow). |
Beta Was this translation helpful? Give feedback.
-
Any ongoing activity with this feature? This would be very much needed. Most of the issues I'm having with the Wagtail at the moment comes from the fact that there is no way to extend the Page model. |
Beta Was this translation helpful? Give feedback.
-
Converting this to Discussions. I believe this is happening / has happened, albeit very slowly. There’s RFC 53: Swappable Page model that badly needs reviews. |
Beta Was this translation helpful? Give feedback.
-
So I have this problem with Wagtail that sometimes (or more like, usually) main models (wagtailcore.Page, wagtailimages.Image, etc.) need to have some additional functionality or overrides to existing functionality.
Consider for example making Page translatable without duplicating trees. One would use something like django-modeltranslation to do that but then all the slug/url_path related functions have to be overriden to handle translated urls properly. You could of course write a Mixin and extend all your Page extending models with that, but some of Page's core functionality doesn't necessarily use
instance.specific
which means that the only way to override Page's functionality is monkey-patching. And everyone knows how bad monkey-patching is :)Django has this very underused feature called swappable models (as used in django.contrib.auth.User). It would be great if Wagtail's core models would be swappable. This would be as simple as moving all implementation to abstract base models (like what is already the case with Image model) and leaving actual model empty with only swappable option in it's Meta. Like this:
Then implement a simple function
get_page_model
which returns the actual Page model and replace all cases of directPage
class usage withget_page_model()
.I have attempted a similar refactoring in django-filer and there are really only pros and no cons with this approach. It would all be 100% backwards-compatible. On the other hand, a lot of flexibility is gained this way.
Now I would be willing to provide a pull request for this, but first I wanted to check whether core developers would support such an idea.
Beta Was this translation helpful? Give feedback.
All reactions