On Thu, Sep 9, 2010 at 1:59 PM, Russell Keith-Magee
<russ...@keith-magee.com> wrote:
> 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)
>>
So how does this work? Where do args come from?
>>
>> 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.
>
>
Personally I think LazyForeignKey is a bad pattern, that being said
it's totally possible to implement right now, there is nothing needed
in Django core.
Alex
--
"I disapprove of what you say, but I will defend to the death your
right to say it." -- Voltaire
"The people's good is the highest law." -- Cicero
"Code can always be simpler than you think, but never as simple as you
want" -- Me
--
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.
