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.

Reply via email to