On Thu, Sep 9, 2010 at 10:24 PM, Javier Guerra Giraldez
<jav...@guerrag.com> wrote:
> from Eric Florenzano's slide 41:
>
> In models.py:
>
> class Favorite(models.Model):
> item = LazyForeignKey(‘fave’)
> user = ForeignKey(User)
> date = DateTimeField(default=utcnow)
>
>
> In settings.py:
>
> LAZY_FKS = {‘fave’: ‘pages.models.Page’}
>
>
> I share the dislike for generic relationships; but don't think this
> solution is particularly elegant, nor flexible enough.
>
> what about giving parameters to the apps? something like:
>
> INSTALLED_APPS = (
> 'django.contrib.auth',
> 'django.contrib.contenttypes',
> 'django.contrib.sessions',
> 'django.contrib.sites',
> 'django.contrib.admin',
> ('debug_toolbar', {
> 'INTERCEPT_REDIRECTS': False,
> 'INTERNAL_IPS': ('127.0.0.2',),
> }),
> 'django_extensions',
> ('favorites', {
> 'fave': ‘pages.models.Page',
> }),
> 'comercial',
> 'specs',
> )
>
>
> and in favorites.models.py:
>
> class Favorite(models.Model):
> item = LazyForeignKey(args[‘fave’])
> user = ForeignKey(User)
> date = DateTimeField(default=utcnow)
>
>
> this helps to reduce global settings pollution, simply by binding a
> global ('args' in this example) to the respective app's parameter
> dictionary.
>
> it could even allow a project to import a single app twice with
> different parameters:
>
> INSTALLED_APPS = (
> ...
> ('favoritebooks', {
> 'APP_MODULE': 'favorites',
> 'fave': ‘pages.models.Book',
> }),
> ('favoritepages', {
> 'APP_MODULE': 'favorites',
> 'fave': ‘pages.models.Page',
> }),
> 'comercial',
> 'specs',
> )
>
> here, APP_MODULE tells Django where to import the app from, by default
> it would be the app name (as now), but specifying it separately allows
> the user to give a different name to the app in the project's context.
>
> toughts?
What you're proposing here is two things: a LazyForeignKey, and
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.
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.
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.
