Re: Class based models
Sorry, missed your reply somehow, > > The line in question, however, should respect subclasses. So your > example wouldn't fail in the case of a proper subclass. > I've heard this claim before, But per my example above it doesn't. What am I doing wrong there? -- 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.
Re: Class based models
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 "", line 1, in > File "...django/db/models/fields/related.py", line 318, in __set__ > self.field.name, self.field.rel.to._meta.object_name)) > ValueError: Cannot assign "": > "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): > > > > >
Re: Class based models
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 "", line 1, in File "...django/db/models/fields/related.py", line 318, in __set__ self.field.name, self.field.rel.to._meta.object_name)) ValueError: Cannot assign "": "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 > &
Re: Class based models
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.
Re: Class based models
I may be dense but is this the functional equiv of cobtrib.comments
get_model()?
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.
Class based models
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/22875fd287d0aa81/313b7bb67f24ad2f
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/0862cecb358d
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/2b8eb68e8ee5
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.
