On Thu, Sep 23, 2010 at 5:55 PM, Klaas van Schelven <klaasvanschel...@gmail.com> wrote: > On Sep 23, 2:01 am, Russell Keith-Magee <russ...@keith-magee.com> > wrote: > > So, we run into a few problems: > * How do we extend the models from the original extendible > application? > For this to work, we need to provide hooks in the application for > extendiblity. In the case of models, such a hook would be twofold: > 1. an abstract model to extend to provide a baseline (a default with > the minimum amount of fields) > 2. something overridable that is referred to by the rest of our app, > providing the concrete instance of [1] in the plain vanilla app, and > the concrete instance plus extensions in our extended app. (the actual > hook)
Sure. Abstract models form the first part of this; the 'reference to the concrete instance' is a known problem -- the most obvious example of this surfacing is defining a custom User class to use in contrib.auth. Alex provides one possible solution (join models) in his talk; another (LazyForeignKey) was raised by Eric Florenzano in his keynote [1]. However, this is still very much an open area of debate. Any suggestions are welcome. [1] http://djangocon.blip.tv/file/4112452/ > * how do we refer to ourselves from the various parts of the > extendible application? > Self-referral with overrides is a solved problem in the object > oriented world ("inheritance"). However, it's impossible in Django's > standard way of organizing apps, because we all use modules (not > classes or instances) for the various parts of the app ("models.py", > "views.py" etc). > It is not possible to pass context into a module (other than monkey > patching it) > > Every views.py begins with a bunch of imports from the associated > models.py, tying the views into those particular app's models. My > alternative would be like so: > > class View(...): > def page_detail(self, request, pk=None): > page = self.models.Page.objects.get(pk=pk) > return render_to_response(.... page ...) > > For models: > > class Models(...): > def get_Page(self): > class Page(models.Model): > #abstract > category = models.ForeignKey(self.models.Category) > return Page > Page = property(get_Page) > > (The above is a bit less elegant than the views example because models > are classes and the following therefor does not work:) > > class Models(...) > class Page(self, model.Model): > ... > category = models.ForeignKey(self.models.Category) > > If anyone has an example of how to do this without a property I'd be > much obliged. Sure. There's at least two approaches. The first -- a method based approach -- is used by contrib.auth (amongst others): def my_view(request, arg1, arg2, klass=Page): objects = klass.objects.filter(arg1=arg1, arg2=arg2) ... The second is the class based approach, used by contrib.admin (and others), which is to define a class-based view, and provide methods like get_objects() that you can subclass to perform whatever behaviour you need. > Views.py methods generally have two types of parameters: > 1. Those that are passed in via urls.py from the request path. Love > 'em, couldn't live without 'em. This is what you're talking about. > 2. Those we add (with usefull defaults) to make our app "reusable". > What I was saying, is that I consider these in particular as unusable > in the general sense. If I subclass the idea of address in an address > book app (to add some field), would it make sense to refer to the > subclassed address class in every call to every single view function? > I'd say no. I'd rather say "give me my views where each view > understands that it should use the improved address class). Sure. And that's why you use class-based views. That's why Django's admin is a class. That's also why Django is in the process of getting a class-based view framework - again, from DjangoCon, see Ben Firshman's talk [2] [2] http://blip.tv/file/4109272 Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
