Re: parameterized apps (was: Re: Eric Florenzano's presentation slides)

2010-09-10 Thread Russell Keith-Magee 
On Fri, Sep 10, 2010 at 6:37 AM, Javier Guerra Giraldez
 wrote:
> On Thu, Sep 9, 2010 at 3:59 PM, Russell Keith-Magee
>  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.

Re: parameterized apps (was: Re: Eric Florenzano's presentation slides)

2010-09-09 Thread Arthur Koziel 

On Sep 9, 2010, at 7:24 AM, Javier Guerra Giraldez wrote:

> 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',
> )

Hey Javier,

this approach has been discussed in my GSOC proposal thread[0]. In the end, we 
decided to leave INSTALLED_APPS as strings to maintain backwards compatibility. 
There are also some other resources which you can find on the wiki[1]. You can 
read through my final status report if you're interested in how the gsoc 
went[2]. I'm currently at DjangoCon and we're going to use the sprints to look 
into how the app-loading branch can be integrated into trunk.

Arthur

[0]: 
http://groups.google.com/group/django-developers/browse_thread/thread/4cca2086dd485879/0cee4bc0557aa9cc
[1]: http://code.djangoproject.com/wiki/SummerOfCode2010#Apploading
[2]: 
http://groups.google.com/group/django-developers/browse_thread/thread/3d730dd8b6653dbb/cd6ce11986aeb162

-- 
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.

Re: parameterized apps (was: Re: Eric Florenzano's presentation slides)

2010-09-09 Thread Russell Keith-Magee 
On Fri, Sep 10, 2010 at 6:42 AM, Javier Guerra Giraldez
 wrote:
> On Thu, Sep 9, 2010 at 4:02 PM, Alex Gaynor  wrote:
>> So how does this work?  Where do args come from?
>
> args (for lack of a better name) is the same dictionary passed as the
> second part of the tuple in the INSTALLED_APPS list.
>
> when Django loads each app, if the entry in INSTALLED_APPS is a tuple,
> the first member is the app name, and the second one is made available
> to the app as 'args'.

Yes - but you're glossing over the important part. You say args is
"made available" - how? Based on your example:

>  class Favorite(models.Model):
>      item = ForeignKey(args[‘fave’])

args must be in the global namespace, which means you have to have:

from somewhere import args

before your model definition. What is the 'somewhere'?

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.

Re: parameterized apps (was: Re: Eric Florenzano's presentation slides)

2010-09-09 Thread Javier Guerra Giraldez 
On Thu, Sep 9, 2010 at 4:02 PM, Alex Gaynor  wrote:
>>> 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?

args (for lack of a better name) is the same dictionary passed as the
second part of the tuple in the INSTALLED_APPS list.

when Django loads each app, if the entry in INSTALLED_APPS is a tuple,
the first member is the app name, and the second one is made available
to the app as 'args'.


((erratum: in this case, we don't need any 'LazyForeignKey', the usual
'ForeignKey' works:

  class Favorite(models.Model):
  item = ForeignKey(args[‘fave’])
  user = ForeignKey(User)
  date = DateTimeField(default=utcnow)

))


-- 
Javier

-- 
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.

Re: parameterized apps (was: Re: Eric Florenzano's presentation slides)

2010-09-09 Thread Javier Guerra Giraldez 
On Thu, Sep 9, 2010 at 3:59 PM, Russell Keith-Magee
 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.

> 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.

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 :-)


-- 
Javier

-- 
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.

Re: parameterized apps (was: Re: Eric Florenzano's presentation slides)

2010-09-09 Thread Patryk Zawadzki 
On Thu, Sep 9, 2010 at 10:59 PM, Russell Keith-Magee
 wrote:
> 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.

See the blog link I posted, there I propose a factory pattern that
allows you to (1) extend the base factory class (2) use the factory to
create the actual Django model in your own app, passing any missing
bits the factory might be expecting.

It solves the "lazy binding" case and also lets you create more than
one model with the same structure and functionality attached.

As for views I recommend something along the lines of:

url(r'^bar/', include('fooapp.urls'), {'model': Bar}),
url(r'^baz/', include('fooapp.urls'), {'model': Baz}),

-- 
Patryk Zawadzki

-- 
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.

Re: parameterized apps (was: Re: Eric Florenzano's presentation slides)

2010-09-09 Thread Alex Gaynor 
On Thu, Sep 9, 2010 at 1:59 PM, Russell Keith-Magee
 wrote:
> On Thu, Sep 9, 2010 at 10:24 PM, Javier Guerra Giraldez
>  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.

Re: parameterized apps (was: Re: Eric Florenzano's presentation slides)

2010-09-09 Thread Russell Keith-Magee 
On Thu, Sep 9, 2010 at 10:24 PM, Javier Guerra Giraldez
 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.

Re: parameterized apps (was: Re: Eric Florenzano's presentation slides)

2010-09-09 Thread burc...@gmail.com 
Hi Javier,

after GSoC 2010, we have
http://socghop.appspot.com/gsoc/student_project/show/google/gsoc2010/django/t127230758002
feature at 
http://code.djangoproject.com/browser/django/branches/soc2010/app-loading

Not that good syntax, but this solution can help you!

P.S. The more testers we have, the faster the branch will be
integrated into the trunk!

On Thu, Sep 9, 2010 at 9:24 PM, Javier Guerra Giraldez
 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?
>
> --
> Javier
>
> --
> 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.
>
>



-- 
Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov,
MSN: bu...@live.com

-- 
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.

Re: parameterized apps (was: Re: Eric Florenzano's presentation slides)

2010-09-09 Thread Patryk Zawadzki 
On Thu, Sep 9, 2010 at 4:24 PM, Javier Guerra Giraldez
 wrote:
> from Eric Florenzano's slide 41:
> (...)

You might want to take a look at my little sandbox here:

http://room-303.com/blog/2010/04/27/django-abstrakcji-ciag-dalszy/

(Sorry the post is in Polish but the only interesting part is the code)

-- 
Patryk Zawadzki

-- 
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.

parameterized apps (was: Re: Eric Florenzano's presentation slides)

2010-09-09 Thread Javier Guerra Giraldez 
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?

-- 
Javier

-- 
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.