On Mon, Sep 24, 2012 at 12:33 PM, Daniel Sokolowski < daniel.sokolow...@klinsight.com> wrote:
> It also seems the current abstract model mechanism can do everything a > model library can minus the model prefixing and the model grouping; that > though I would just tackle using a naming convention, i.e. > SimpleLibraryBook, ExtendedLibraryBook, with a BaseBook abstract class. > There's a big thing you cannot do without grouping models: you can't have an abstract base class relate to another abstract base class. Django's foreign key mechanism doesn't know how to relate to a to-be-instantiated concrete class. This is more or less the same problem that is solved by Russell's User model switching code: you want libraries to relate to the User model, but you also want application writers to subclass the User model. Russell's solution is bottom-up: you swap out the User model at runtime, and refer to it indirectly everywhere. Jonathan's solution is top down: you instantiate all your model classes together, resolving references at load time. Jonathan's solution is nice because it lets you instantiate multiple copies of the same base. Russell's is nice because it doesn't require invasive architectural changes, such as moving all your base classes to a single factory. I like this solution. I don't think it strictly has to be in core though: if I wanted to distribute a blueprint model, I can just depend on django-model-blueprint without even requiring any changes to INSTALLED_APPS, which means the only benefit to being in core is canonicalizing the pattern. Best, Alex Ogier -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
