On Wed, Apr 7, 2010 at 8:23 PM, Vinay Sajip <vinay_sa...@yahoo.co.uk> wrote: > > On Apr 7, 12:40 pm, Russell Keith-Magee <freakboy3...@gmail.com> > wrote: >> >> I agree with Alex - there's a lot more detail needed here. How will I >> get access to the App instance that a model belongs to? How will >> legacy attributes like db_prefix be proxied? What is the order of >> precedence when a model and an app disagree on db_prefix? >> > > Agreed that a more detailed specification is required, but wouldn't at > least some of that detailing be part of the actual GSoC work?
It's fair to assume that there will always be *some* details that are worked out as part of the GSoC work. My intention isn't to try and nail down all the details before the project starts - it's to try and work out how much Arthur has thought about the problem, and how well he can communicate what he is thinking. The GSoC application process is a lot like a job interview. Although Django itself isn't paying the stipend to students, we are going to commit a lot of resources to mentoring a student. As a result, we aren't going to take on students just to make up the numbers. Asking questions like this one allows me to kill 3 birds with 1 stone - I get to improve the design, *and* I get to see the design skills of the prospective student in action, *and* I get to see how well the prospective student is able to communicate those designs to the wider community. >> For the record - I don't think the "multiple versions of a single app" >> problem is one worth solving. I'm not even convinced it can be solved >> at all, for all the reasons Florian identified, and then some. > > I agree, but IIRC it was quoted as one reason why this feature was > left out of the running in the recent Django revisions. It doesn't > make a lot of sense to me for any app where models are concerned, and > I believe there would be no point in duplicating the models for > multiple instances of an app. Not to my reading. The reason for rejection at official voting has always been "incomplete design". I can see that the subject of multi-deployed apps has come up in the past, but it's also been identified as a *hard* problem, and possibly one that doesn't need solving. Unless someone can provide a particularly compelling use case, I'm inclined to put it on the ignore pile. >> Although it may have been part of the original use case for #3591, >> much of that use case has since been replaced by namespaced URLs and >> class-based applications. If you're going to tackle this problem, I'd >> rather see you concentrate on issues like: > > Class-based applications? Can someone point me to some of those? django.contrib.admin is the most notable example. Yours, Russ Magee %-) -- 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.
