On Fri, Sep 10, 2010 at 6:37 AM, Javier Guerra Giraldez <jav...@guerrag.com> wrote: > On Thu, Sep 9, 2010 at 3:59 PM, Russell Keith-Magee > <russ...@keith-magee.com> wrote: > >> What you're proposing here is two things: a LazyForeignKey, and >> configurable applications. > > not really, it's only configurable applications. once you have that, > it's easy to make the ForeignKey depend on a parameter.
Sure, but my point is that you can have configurable applications without having a way to do LazyForeignKeys, and you can have LazyForeignKeys without needing configurable applications. >> Configurable apps were the subject of Arthur Koziel's GSoC project >> this year. From my conversations with Jannis this week at DjangoCon, >> it sounds like this GSoC code is in pretty good shape. However, in >> order to smooth the path, we will probably end up landing some >> preliminary work for 1.3, and land the final patch for 1.4. > > yes, i've just seen the link posted by Yuri. maybe GSoC projects > could use some more visiblity, a Git fork of the whole Django code > doesn't make it easy to know what's happening there. I'll grant that it isn't easy to find out about our GSoC projects unless you're keeping a close eye on the posting to django-dev while the SoC is underway. Even then, it's only as good as the updates that come from the student, and Arthur didn't post that many updates during his project. Our GSoC process is something we only get one chance a year to improve; improving visibility for people who aren't regular contributors is certainly something worth looking at. > judging just from the GSoC proposal, an app object could make a lot of > OOP goodness available. > >> The LazyForeignKey pattern has been proposed by a number of parties; >> it's an interesting idea that is worth some serious consideration. >> There are some issues with implementation (e.g., exactly how to >> describe the relationship in a clean way that doesn't require us to >> import settings in order to define models), but these issues shouldn't >> be too hard to sort out. I'll see if I can get some discussion going >> at the sprints over the next couple of days. > > it all that really necessary? i'd think that just not using hardcoded > constants for the model class or name buys a _lot_ of flexibility. > > of course, that's easily doable right now. the simplest case would be > just using settings variables: > > in settings.py: > > FAVORITES_FAVE_MODEL=‘pages.models.Page' > > in favorites/models.py: > > class Favorite(models.Model): > item = ForeignKey(settings.FAVORITES_FAVE_MODEL) > user = ForeignKey(User) > date = DateTimeField(default=utcnow) > > > but that's just ugly, and pollutes a global namespace. hence, > configurable apps :-) It's also not possible to implement it that way. Like I said, you need to be able to do this *without* importing settings. 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.
