Hey Russell, Do you think a round table discussion in a real person context with whiteboards and the best of the bunch (ie, at Django con or similar event) would be a good time/place to re architecture of the abstraction layers, perhaps to address some of the concerns brought up in the slide show by Eric? By abstraction layers I don't just refer to the "app" (which I don't see to be a problem as much as others do, although I don't like how so many apps have models in them). I'm also referring to things like; putting global functionality into urls.py, tight coupling of built-in apps, etc.
Michael On Sep 23, 5:40 am, Russell Keith-Magee <russ...@keith-magee.com> wrote: > 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.
