librelist archives

« back to archive

REGISTRATION_OPEN in geonode.maps.context_processors

REGISTRATION_OPEN in geonode.maps.context_processors

From:
David Winslow
Date:
2010-06-16 @ 20:39
It seems a little weird that we are introducing a dependency on the 
(configuration for the) django-registration app in geonode.maps:


http://github.com/GeoNode/geonode/blob/master/src/GeoNodePy/geonode/maps/context_processors.py#L8

Shouldn't this sort of configuration be used at the project level 
instead of the app level?

-d

Re: [geonode] REGISTRATION_OPEN in geonode.maps.context_processors

From:
Ariel Nunez
Date:
2010-06-16 @ 21:08
> Shouldn't this sort of configuration be used at the project level
> instead of the app level?
>
> -d
>

David, I think your assessment is correct. We should create a
project-wide context_processors file, add it there, and then reference
something like geonode_tags. I believe we can put SITENAME in the
project wide one too, right?

Ariel.

Re: [geonode] REGISTRATION_OPEN in geonode.maps.context_processors

From:
David Winslow
Date:
2010-06-16 @ 21:19
On 06/16/2010 05:08 PM, Ariel Nunez wrote:
>> Shouldn't this sort of configuration be used at the project level
>> instead of the app level?
>>
>> -d
>>
>>      
> David, I think your assessment is correct. We should create a
> project-wide context_processors file, add it there, and then reference
> something like geonode_tags. I believe we can put SITENAME in the
> project wide one too, right?
>
> Ariel.
>    
Yep, SITENAME doesn't have much to do with maps either.  On that topic, 
I've been looking into the Django sites framework (as noted on this 
ticket: http://projects.opengeo.org/CAPRA/ticket/534) .  It seems that 
using the sites framework is a more common way of handling that 
information, so I guess we should replace the configuration option with 
that.  Of course, the sites framework adds some overhead to setting up a 
new site since it keeps the name/domain/id mapping in the database, so 
maybe it's more trouble than it's worth?  I haven't looked closely 
enough at Pinax to know whether using the sites framework would make a 
difference with respect to Pinax integration, but, Ariel, do you have 
any experience with that?

--
David Winslow
OpenGeo - http://opengeo.org/

REGISTRATION_OPEN in geonode.maps.context_processors

From:
Ariel Nunez
Date:
2010-06-16 @ 21:26
Well, they have both a SITE_NAME config option and are using the sites
framework:


http://github.com/pinax/pinax/blob/master/pinax/projects/basic_project/settings.py#L137


http://github.com/pinax/pinax/blob/master/pinax/projects/basic_project/settings.py#L202

And they add the SITE_NAME project wide like this:

http://github.com/pinax/pinax/blob/master/pinax/core/context_processors.py

Personally, I have always used the sites framework (especially when
handling outgoing emails and rss feeds). I think the fact that they
are using SITE_NAME is mostly historic and not something they have
really thought trough.

Ariel.