Hmm... I do see what you're saying. The line in question, however, should respect subclasses. So your example wouldn't fail in the case of a proper subclass.
I checked out that thread and I saw Russel commented on it and ironically he mentioned contrib.comments as well. One thing you say is 'providing abstract models feels really awkward'-- Why? It seems like you almost want an 'attributes_for' option in the model Meta options whereby one model can stand-in for another model. Still, a lot of your proposal seems to rely on a developer's 'best practices'--aka something akin to contrib.comments' get_model() use in views and form (which can't be codified with patches, really). -Steve PS: One nag I have about get_model() is that is singular. Sure, contrib.comments happens to only have one extensible but what about when there's more? On Sep 27, 5:45 pm, Klaas van Schelven <klaasvanschel...@gmail.com> wrote: > There's a quite a few things that I don't like about the get_model > approach. I'll focus on one though: contrib.comment's own models do > not respect it. > > Consider a customized model for comments (the model MyComment in > my_comments) > so in settings.py we put: > COMMENTS_APP = 'my_comments' > > then we do the following: > from django.contrib.comments.models import CommentFlag > flag = CommentFlag() > from django.contrib.comments import get_model > mycomment = get_model().objects.get() > flag.comment = mycomment > > Traceback (most recent call last): > File "<console>", line 1, in <module> > File "...django/db/models/fields/related.py", line 318, in __set__ > self.field.name, self.field.rel.to._meta.object_name)) > ValueError: Cannot assign "<MyComment: MyComment object>": > "CommentFlag.comment" must be a "Comment" instance. > > You see the problem? Any help thinking about the solution is much > appreciated. > > Klaas > > On Sep 27, 7:57 pm, "subs...@gmail.com" <subs...@gmail.com> wrote: > > > > > I thought that's what get_model did? > > > You specify your own comments app and register your own (subclass or > > other) model within that function and its used throughout the original > > app. > > > On Sep 27, 3:02 am, Klaas van Schelven <klaasvanschel...@gmail.com> > > wrote: > > > > On Sep 27, 4:17 am, "subs...@gmail.com" <subs...@gmail.com> wrote: > > > > > I may be dense but is this the functional equiv of cobtrib.comments > > > > get_model()? > > > > Nope. > > > Rather, it's a way to subclass models that are provided by reusable > > > apps, and letting the reusable app use the subclassed instance > > > throughout. > > > > > On Sep 26, 8:28 am, Klaas van Schelven <klaasvanschel...@gmail.com> > > > > wrote: > > > > > > Hi all, > > > > > > I'm looking for a bit of input for making Django's apps a bit more > > > > > extendable, either by modifying Django or (preferably) by coming up > > > > > with a common language on top op Django. The main painpoint are > > > > > extendable models. The idea of 'extendable' is that models from > > > > > reusable apps can be extended in any concrete project. The reusable > > > > > apps should refer to their own models in such a way that they will get > > > > > the concrete implementation (extension). > > > > > Class based models if you will. > > > > > > Context can be found > > > > > here:http://groups.google.com/group/django-users/browse_thread/thread/2287... > > > > > > Currently, apps usually refer to their own models by simply importing > > > > > them from models.py and referring to them. This obviously will not > > > > > work, so any solution will need some kind of registry, or instance of > > > > > "app". If "app" is an instance of a class referring to it can be done > > > > > in an extendible way (simply by using Python's inheritance mechanism). > > > > > > I've put an example of this approach > > > > > here:http://bitbucket.org/vanschelven/extendible_app_experiment/src/0862ce... > > > > > > Which incorporates the above idea of an app class & instance in blog/ > > > > > __init__.py. > > > > > > abstract_blog/abstract_models.py and blog/models.py > > > > > > The key sections are: > > > > > (in abstract_models) > > > > > > def get_AbstractPage(self): > > > > > class AbstractPage(models.Model): > > > > > body = models.TextField() > > > > > category = models.ForeignKey(self.app.models.Category) > > > > > > class Meta: > > > > > abstract = True > > > > > #app_label = 'abstract_blog' > > > > > return AbstractPage > > > > > AbstractPage = property(get_AbstractPage) > > > > > > (in models) > > > > > def get_Category(self): > > > > > class Category(self.AbstractCategory): > > > > > some_added_field = models.IntegerField() > > > > > return Category > > > > > Category = property(get_Category) > > > > > > As you can see, it is possible to refer to "the apps real > > > > > implementation of Category" (self.app.models.Category, or just > > > > > self.Category) from the abstract model. Less neat: the cruft that's > > > > > needed to pass self into AbstractPage for reference (3 lines per > > > > > class: def, return & property). > > > > > > In a more recent version I've managed to factor those lines away at > > > > > the cost of a lot of > > > > > magic.http://bitbucket.org/vanschelven/extendible_app_experiment/src/2b8eb6... > > > > > > class AbstractModels(object): > > > > > #... > > > > > class AbstractPage(shmodels.Model): > > > > > body = shmodels.TextField() > > > > > category = > > > > > shmodels.ForeignKey(Zelf("app.models.Category")) > > > > > > Neet uh? Self referral without an actual introduction of "self". > > > > > > I may look for the general case of Zelf & Zelf2 and shmodels and > > > > > whatever... but I'd like to know that this is a path worth following. > > > > > In other words: am I missing really obvious, more simple solutions > > > > > here? > > > > > > ciao, > > > > > Klaas -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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.
