librelist archives

Re: [geonode] GeoNode customization

From:

Matt Bertrand

Date:

2010-10-30 @ 13:33

Hi,

I'm working on a GeoNode customization as well.  Some of the features  
I need to add are customizable header banners for user-created maps,  
querying and highlighting selected features on the map, user defined  
layer categories, and displaying the layer tree organized by category.  
(http://github.com/mbertrand/cga-worldmap).  This is for the next  
version of "WorldMap", a web mapping platform used by Harvard's Center  
for Geographic Analysis.  We decided to use GeoNode as the basis for  
it since it already has many of the features we were hoping to  
include, such as data uploads, permission controls, style editing, etc.

So far I haven't overridden any existing patterns in urls.py, but I  
have added some new ones.  I've needed to modify several of the  
default templates, and I've quite a few changes to the views and  
models.  I also added new functions to the GeoExplorer javascript file  
that renders the map view (for searching, querying, and highlighting  
layers).  I've been merging the latest code from geonode every few  
days, and so far the merge conflicts have been pretty trivial so far,  
though they won't necessarily continue to be so simple.

Thanks for the useful tips!

-Matt


On Oct 28, 2010, at 8:51 PM, Christian Spanring wrote:

> Thanks! There are a couple of good hints how to approach our issue -  
> duplicating the template dir structure and changing the template dir  
> setting seems like a good way to start. I also like the idea of  
> having a fallback to the default geonode.
>
> A colleague pointed me to the class based views discussion in Django  
> Development http://docs.djangoproject.com/en/dev/topics/class-based-views/
>
> From what I read there, this seems to solve exactly what I'm trying  
> to do.
>
> Christian
>
> On Oct 28, 2010, at 8:09 PM, David Winslow wrote:
>
>> Well, we haven't done a lot of heavily customized applications, but  
>> in the future I think it would be great t o have a good plan for  
>> people who want to dig into Django a bit and use GeoNode as a  
>> platform for their own tools.  So I'm glad to hear you're looking  
>> into it.
>>
>> In previous experiments with having an alternative theme building  
>> off the core GeoNode, we had a setup where the alternate site had  
>> its own settings.py, where early in the Python file, there was a  
>> line like:
>>
>> from geonode.settings import *
>>
>> Then we modified various values as needed (INSTALLED_APPS =  
>> INSTALLED_APPS + ('myapp',)).  I think this approach worked ok, but  
>> it was a little cumbersome to keep the customized site up to date  
>> with the main site as new pages and apps were added.  I'm not sure  
>> what a better solution might be... we have started to recognize a  
>> "local_settings.py" file next to the GeoNode settings to  
>> accommodate site-specific changes in a file that won't be  
>> overwritten on updates, but I don't think that approach works well  
>> if you want to add extra Django apps to the site.
>>
>> A similar approach should work pretty well for the urls.py though.   
>> You can just import geonode.urls in your urls.py and write  
>> "urlpatterns = urlpatterns + geonode.urls.urlpatterns" to have the  
>> GeoNode URLs used as a fallback if none of your URL patterns match  
>> a request.
>>
>> Django also has a nice system for overriding templates.  If you  
>> override TEMPLATE_DIRS to add an extra directory containing your  
>> customized templates before the directories it already uses, then  
>> those templates will override. So you would have templates in  
>> places like like [/opt/mysite/geonode/login.html] and your settings  
>> would have an entry like:
>>
>> TEMPLATE_DIRS = "/opt/mysite/", \
>>                 path_extrapolate('geonode/templates'), \
>>                 path_extrapolate('geonode/maps/templates'), \
>>                 path_extrapolate('django/contrib/admin/templates',  
>> 'django'),
>>
>> Don't worry about the path_extrapolate function there, it  
>> duplicates some path-munging functionality already present in the  
>> Django template system and will probably be going away in a release  
>> soon after 1.0.  1.1, along with other Pinax integration and  
>> general adoption of Django idioms, should also be using the django- 
>> staticfiles app to provide similar functionality for CSS and  
>> JavaScript resources, should you need to override or add on to  
>> what's used in GeoNode.
>>
>> I hope this provides you some good places to start investigating.
>>
>> --
>> David Winslow
>> OpenGeo - http://opengeo.org/
>>
>> On Thu, Oct 28, 2010 at 1:44 PM, Spanring, Christian <CSpanring@mapc.org 
>> > wrote:
>> Hi,
>>
>> I've started customizing a GeoNode instance and was wondering if  
>> other users here are trying to do something similar. Mainly to  
>> check/discuss if the path I'm going makes sense.
>>
>> The goal is to maintain maximum forward compatibility with the main  
>> GeoNode repository (painless future updates/merges). At the same  
>> time, we obviously want a custom design for and add other  
>> functionality (Django apps) to our GeoNode instance.
>>
>> So far I've thought about a few approaches:
>>
>> A) override urls.py with my app's urls.py 
http://github.com/cspanring/geonode/blob/develop/src/GeoNodePy/geonode/urls.py#L16

>>  and duplicating code from the default GeoNode apps seems like a  
>> really bad idea.
>>
>> B) modifying the default templates 
http://github.com/cspanring/geonode/blob/develop/src/GeoNodePy/geonode/templates/page_layout.html#L12

>>  would break forward compatibility at some point. That solution  
>> worked as quick hack to have a basic custom design online but I  
>> would rather not touch the default templates in the long run.
>>
>> C) specifying templates generally in urls.py 
http://github.com/cspanring/geonode/blob/develop/src/GeoNodePy/geonode/urls.py#L20

>>  instead of hard-coding them into views would allow users to  
>> customize frontend designs, like switching templates, pretty  
>> easily. That's my favorite approach so far but doing that by  
>> myself, changing all views to that schema, would probably break  
>> forward compatibility (seamless merging with future GeoNode updates/ 
>> fixes) of our instance too.
>>
>> Any other thoughts?
>>
>> Thanks,
>> Christian
>>
>> Please be advised that the Massachusetts Secretary of State  
>> considers e-mail to be a public record, and therefore subject to  
>> the Massachusetts Public Records Law, M.G.L. c. 66 ? 10.
>>
>

On Oct 30, 2010, at 15:33 , Matt Bertrand wrote:

> Hi,
> 
> I'm working on a GeoNode customization as well.  Some of the features I 
need to add are customizable header banners for user-created maps, 
querying and highlighting selected features on the map, user defined layer
categories, and displaying the layer tree organized by category. 
(http://github.com/mbertrand/cga-worldmap).  This is for the next version 
of "WorldMap", a web mapping platform used by Harvard's Center for 
Geographic Analysis.  We decided to use GeoNode as the basis for it since 
it already has many of the features we were hoping to include, such as 
data uploads, permission controls, style editing, etc.
> 
> So far I haven't overridden any existing patterns in urls.py, but I have
added some new ones.  I've needed to modify several of the default 
templates, and I've quite a few changes to the views and models.  I also 
added new functions to the GeoExplorer javascript file that renders the 
map view (for searching, querying, and highlighting layers).  I've been 
merging the latest code from geonode every few days, and so far the merge 
conflicts have been pretty trivial so far, though they won't necessarily 
continue to be so simple.

One hint: with new map composer/viewer features that we add, we no longer 
code them directly into GeoExplorer.js. Instead, we create self-contained 
tool plugins that inherit from gxp.plugins.Tool 
(https://github.com/opengeo/gxp/blob/master/src/script/plugins/Tool.js). 
The GetFeatureInfo tool 
(https://github.com/opengeo/gxp/blob/master/src/script/plugins/WMSGetFeatureInfo.js)
used in the synth branch is a first example of this: 
https://github.com/GeoNode/geonode/commit/5878a29a69acad9956025547c9fd35282a07a974

If you follow this practice, it will also be simpler for you to merge 
updates into your branch. Note, however, that the Tool.js API is still 
young and may change as well.

Regards,
Andreas.

> 
> Thanks for the useful tips!
> 
> -Matt
> 
> 
> On Oct 28, 2010, at 8:51 PM, Christian Spanring wrote:
> 
>> Thanks! There are a couple of good hints how to approach our issue - 
duplicating the template dir structure and changing the template dir 
setting seems like a good way to start. I also like the idea of havin g a 
fallback to the default geonode.
>> 
>> A colleague pointed me to the class based views discussion in Django 
Development http://docs.djangoproject.com/en/dev/topics/class-based-views/
>> 
>> From what I read there, this seems to solve exactly what I'm trying to do.
>> 
>> Christian
>> 
>> On Oct 28, 2010, at 8:09 PM, David Winslow wrote:
>> 
>>> Well, we haven't done a lot of heavily customized applications, but in
the future I think it would be great t o have a good plan for people who 
want to dig into Django a bit and use GeoNode as a platform for their own 
tools.  So I'm glad to hear you're looking into it.
>>> 
>>> In previous experiments with having an alternative theme building off 
the core GeoNode, we had a setup where the alternate site had its own se 
ttings.py, where early in the Python file, there was a line like:
>>> 
>>> from geonode.settings import *
>>> 
>>> Then we modified various values as needed (INSTALLED_APPS = 
INSTALLED_APPS + ('myapp',)).  I think this approach worked ok, but it was
a little cumbersome to keep the customized site up to date with the main 
site as new pages and apps were added.  I'm not sure what a better 
solution might be... we have started to recognize a "local_settings.py" 
file next to the GeoNode settin gs to accommodate site-specific changes in
a file that won't be overwritten on updates, but I don't think that 
approach works well if you want to add extra Django apps to the site.
>>> 
>>> A similar approach should work pretty well for the urls.py though.  
You can just import geonode.urls in your urls.py and write "urlpatterns = 
urlpatterns + geonode.urls.urlpatterns" to have the GeoNode URLs used as a
fallback if none of your URL patterns match a request.
>>> 
>>> Django also has a nice system for overriding templates.  If you 
override TEMPLATE_DIRS to add an extra directory containing your 
customized templates before the directories it already uses, then those 
templates will override. So you would have templates in places like like 
[/opt/mysite/geonode/login.html] and your settings would have an entry 
like:
>>> 
>>> TEMPLATE_DIRS = "/opt/mysite/", \
>>>                 path_extrapolate('geonode/templates'), \
>>>                 path_extrapolate('geonode/maps/templates'), \
>>>                 path_extrapolate('django/contrib/admin/templates', 'django'),
>>> 
>>> Don't worry about the path_extrapolate function there, it duplicates 
some path-munging functionality already present in the Django template 
system and will probably be going away in a release soon after 1.0.  1.1, 
along with other Pinax integration and general adoption of Django idioms, 
should also be using the django-staticfiles app to provide simila r 
functionality for CSS and JavaScript resources, should you need to 
override or add on to what's used in GeoNode.
>>> 
>>> I hope this provides you some good places to start investigating.
>>> 
>>> --
>>> David Winslow
>>> OpenGeo - http://opengeo.org/
>>> 
>>> On Thu, Oct 28, 2010 at 1:44 PM, Spanring, Christian 
<CSpanring@mapc.org> wrote:
>>> Hi,
>>> 
>>> I've started customizing a GeoNode instance and was wondering if other
users here are trying to do something similar. Mainly to check/discuss if 
the path I'm going makes sense.
>>> 
>>> The g oal is to maintain maximum forward compatibility with the main 
GeoNode repository (painless future updates/merges). At the same time, we 
obviously want a custom design for and add other functionality (Django 
apps) to our GeoNode instance.
>>> 
>>> So far I've thought about a few approaches:
>>> 
>>> A) override urls.py with my app's urls.py 
http://github.com/cspanring/geonode/blob/develop/src/GeoNodePy/geonode/urls.py#L16
and duplicating code from the default GeoNode apps seems like a really bad
idea.
>>> 
>>> B) modifying the default templates 
http://github.com/cspanring/geonode/blob/develop/src/GeoNodePy/geonode/templates/page_layout.html#L12
would break forward compatibility at some point. That solution worked as 
quick hack to have a basic custom design online but I would rather not 
touch the default templates in the long run.
>>> 
>>> C) specifying templates generally in urls.py 
http://github.com/cspanring/geonode/blob/develop/src/GeoNodePy/geonode/urls.py#L20
instead of hard-coding them into views would allow users to customize 
frontend designs, like switching templates, pretty easily. That's my 
favorite approach so far but doing that by myself, changing all views to 
that schema, would probably break forward compatibility (seamless merging 
with future GeoNode updates/fixes) of our instance too.
>>> 
>>> Any other thoughts?
>>> 
>>> Thanks,
>>> Christian
>>> 
>>> Please be advised that the Massachusetts Secretary of State considers 
e-mail to be a public record, and therefore subject to the Massachusetts 
Public Records Law, M.G.L. c. 66 ? 10.
>>> 
>> < /div>
> 

-- 
Andreas Hocevar
OpenGeo - http://opengeo.org/
Expert service straight from the developers.

Matt,


> I'm working on a GeoNode customization as well.  Some of the features I
> need to add are customizable header banners for user-created maps, querying
> and highlighting selected features on the map, user defined layer
> categories, and displaying the layer tree organized by category. (
> http://github.com/mbertrand/cga-worldmap).
>

This is really exciting to hear about.

It's hard to tell from these brief descriptions, but I'm curious: are all of
these additions totally custom for your needs, or could any of them be
implemented in a general way and contributed back to the core?

Some of these features sound like things we are working on or plan to in the
future, and it would be great to collaborate.

Please don't be shy about bringing up your needs and progress on this list,
or joining the public developer list at geonode@opengeo.org if you want to
discuss particular patches.

On Oct 28, 2010, at 8:51 PM, Christian Spanring wrote:
>
> Thanks! There are a couple of good hints how to approach our issue -
> duplicating the template dir structure and changing the template dir setting
> seems like a good way to start. I also like the idea of havin g a fallback
> to the default geonode.
>
> A colleague pointed me to the class based views discussion in Django
> Development http://docs.djangoproject.com/en/dev/topics/class-based-views/
>
> From what I read there, this seems to solve exactly what I'm trying to do.
>
> Christian
>
> On Oct 28, 2010, at 8:09 PM, David Winslow wrote:
>
> Well, we haven't done a lot of heavily customized applications, but in the
> future I think it would be great t o have a good plan for people who want to
> dig into Django a bit and use GeoNode as a platform for their own tools.  So
> I'm glad to hear you're looking into it.
>
> In previous experiments with having an alternative theme building off the
> core GeoNode, we had a setup where the alternate site had its own se
> ttings.py, where early in the Python file, there was a line like:
>
> from geonode.settings import *
>
>
> Then we modified various values as needed (INSTALLED_APPS = INSTALLED_APPS
> + ('myapp',)).  I think this approach worked ok, but it was a little
> cumbersome to keep the customized site up to date with the main site as new
> pages and apps were added.  I'm not sure what a better solution might be...
> we have started to recognize a "local_settings.py" file next to the GeoNode
> settin gs to accommodate site-specific changes in a file that won't be
> overwritten on updates, but I don't think that approach works well if you
> want to add extra Django apps to the site.
>
> A similar approach *should* work pretty well for the urls.py though.  You
> can just import geonode.urls in your urls.py and write "urlpatterns =
> urlpatterns + geonode.urls.urlpatterns" to have the GeoNode URLs used as a
> fallback if none of your URL patterns match a request.
>
> Django also has a nice system for overriding templates.  If you override
> TEMPLATE_DIRS to add an extra directory containing your customized templates
> before the directories it already uses, then those templates will override.
> So you would have templates in places like like
> [/opt/mysite/geonode/login.html] and your settings would have an entry like:
>
> TEMPLATE_DIRS = "/opt/mysite/", \
>
>                 path_extrapolate('geonode/templates'), \
>
>                 path_extrapolate('geonode/maps/templates'), \
>
>                 path_extrapolate('django/contrib/admin/templates',
>> 'django'),
>
>
> Don't worry about the path_extrapolate function there, it duplicates some
> path-munging functionality already present in the Django template system and
> will probably be going away in a release soon after 1.0.  1.1, along with
> other Pinax integration and general adoption of Django idioms, should also
> be using the 
django-staticfiles<http://docs.djangoproject.com/en/1.2/howto/static-files/>
app
> to provide simila r functionality for CSS and JavaScript resources, should
> you need to override or add on to what's used in GeoNode.
>
> I hope this provides you some good places to start investigating.
>
> --
> David Winslow
> OpenGeo - http://opengeo.org/
>
> On Thu, Oct 28, 2010 at 1:44 PM, Spanring, Christian <CSpanring@mapc.org>wrote:
>
>> Hi,
>>
>> I've started customizing a GeoNode instance and was wondering if other
>> users here are trying to do something similar. Mainly to check/discuss if
>> the path I'm going makes sense.
>>
>> The g oal is to maintain maximum forward compatibility with the main
>> GeoNode repository (painless future updates/merges). At the same time, we
>> obviously want a custom design for and add other functionality (Django apps)
>> to our GeoNode instance.
>>
>>
>> So far I've thought about a few approaches:
>>
>> A) override urls.py with my app's urls.py
>> 
http://github.com/cspanring/geonode/blob/develop/src/GeoNodePy/geonode/urls.py#L16and
duplicating code from the default GeoNode apps seems like a really bad
>> idea.
>>
>> B) modifying the default templates
>> 
http://github.com/cspanring/geonode/blob/develop/src/GeoNodePy/geonode/templates/page_layout.html#L12would
break forward compatibility at some point. That solution worked as
>> quick hack to have a basic custom design online but I would rather not touch
>> the default templates in the long run.
>>
>> C) specifying templates generally in urls.py
>> 
http://github.com/cspanring/geonode/blob/develop/src/GeoNodePy/geonode/urls.py#L20instead
of hard-coding them into views would allow users to customize
>> frontend designs, like switching templates, pretty easily. That's my
>> favorite approach so far but doing that by myself, changing all views to
>> that schema, would probably break forward compatibility (seamless merging
>> with future GeoNode updates/fixes) of our instance too.
>>
>> Any other thoughts?
>>
>> Thanks,
>> Christian
>>
>> Please be advised that the Massachusetts Secretary of State considers
>> e-mail to be a public record, and therefore subject to the Massachusetts
>> Public Records Law, M.G.L. c. 66 ? 10.
>>
>
> < /div>
>
>
>


-- 
Sebastian Benthall
OpenGeo - http://opengeo.org

Hi Sebastian

> It's hard to tell from these brief descriptions, but I'm curious:  
> are all of these additions totally custom for your needs, or could  
> any of them be implemented in a general way and contributed back to  
> the core?

It's probably a mix of both, and I'd be happy to collaborate and  
contribute any useful parts back to the core.


> Some of these features sound like things we are working on or plan  
> to in the future, and it would be great to collaborate.
>
> Please don't be shy about bringing up your needs and progress on  
> this list, or joining the public developer list at  
> geonode@opengeo.org if you want to discuss particular patches.
>
> On Oct 28, 2010, at 8:51 PM, Christian Spanring wrote:
>
>> Thanks! There are a couple of good hints how to approach our issue  
>> - duplicating the template dir structure and changing the template  
>> dir setting seems like a good way to start. I also like the idea of  
>> havin g a fallback to the default geonode.
>>
>> A colleague pointed me to the class based views discussion in  
>> Django Development 
http://docs.djangoproject.com/en/dev/topics/class-based-views/
>>
>> From what I read there, this seems to solve exactly what I'm trying  
>> to do.
>>
>> Christian
>>
>> On Oct 28, 2010, at 8:09 PM, David Winslow wrote:
>>
>>> Well, we haven't done a lot of heavily customized applications,  
>>> but in the future I think it would be great t o have a good plan  
>>> for people who want to dig into Django a bit and use GeoNode as a  
>>> platform for their own tools.  So I'm glad to hear you're looking  
>>> into it.
>>>
>>> In previous experiments with having an alternative theme building  
>>> off the core GeoNode, we had a setup where the alternate site had  
>>> its own se ttings.py, where early in the Python file, there was a  
>>> line like:
>>>
>>> from geonode.settings import *
>>>
>>> Then we modified various values as needed (INSTALLED_APPS =  
>>> INSTALLED_APPS + ('myapp',)).  I think this approach worked ok,  
>>> but it was a little cumbersome to keep the customized site up to  
>>> date with the main site as new pages and apps were added.  I'm not  
>>> sure what a better solution might be... we have started to  
>>> recognize a "local_settings.py" file next to the GeoNode settin gs  
>>> to accommodate site-specific changes in a file that won't be  
>>> overwritten on updates, but I don't think that approach works well  
>>> if you want to add extra Django apps to the site.
>>>
>>> A similar approach should work pretty well for the urls.py  
>>> though.  You can just import geonode.urls in your urls.py and  
>>> write "urlpatterns = urlpatterns + geonode.urls.urlpatterns" to  
>>> have the GeoNode URLs used as a fallback if none of your URL  
>>> patterns match a request.
>>>
>>> Django also has a nice system for overriding templates.  If you  
>>> override TEMPLATE_DIRS to add an extra directory containing your  
>>> customized templates before the directories it already uses, then  
>>> those templates will override. So you would have templates in  
>>> places like like [/opt/mysite/geonode/login.html] and your  
>>> settings would have an entry like:
>>>
>>> TEMPLATE_DIRS = "/opt/mysite/", \
>>>                 path_extrapolate('geonode/templates'), \
>>>                 path_extrapolate('geonode/maps/templates'), \
>>>                 path_extrapolate('django/contrib/admin/templates',  
>>> 'django'),
>>>
>>> Don't worry about the path_extrapolate function there, it  
>>> duplicates some path-munging functionality already present in the  
>>> Django template system and will probably be going away in a  
>>> release soon after 1.0.  1.1, along with other Pinax integration  
>>> and general adoption of Django idioms, should also be using the  
>>> django-staticfiles app to provide simila r functionality for CSS  
>>> and JavaScript resources, should you need to override or add on to  
>>> what's used in GeoNode.
>>>
>>> I hope this provides you some good places to start investigating.
>>>
>>> --
>>> David Winslow
>>> OpenGeo - http://opengeo.org/
>>>
>>> On Thu, Oct 28, 2010 at 1:44 PM, Spanring, Christian <CSpanring@mapc.org 
>>> > wrote:
>>> Hi,
>>>
>>> I've started customizing a GeoNode instance and was wondering if  
>>> other users here are trying to do something similar. Mainly to  
>>> check/discuss if the path I'm going makes sense.
>>>
>>> The g oal is to maintain maximum forward compatibility with the  
>>> main GeoNode repository (painless future updates/merges). At the  
>>> same time, we obviously want a custom design for and add other  
>>> functionality (Django apps) to our GeoNode instance.
>>>
>>>
>>> So far I've thought about a few approaches:
>>>
>>> A) override urls.py with my app's urls.py 
http://github.com/cspanring/geonode/blob/develop/src/GeoNodePy/geonode/urls.py#L16

>>>  and duplicating code from the default GeoNode apps seems like a  
>>> really bad idea.
>>>
>>> B) modifying the default templates 
http://github.com/cspanring/geonode/blob/develop/src/GeoNodePy/geonode/templates/page_layout.html#L12

>>>  would break forward compatibility at some point. That solution  
>>> worked as quick hack to have a basic custom design online but I  
>>> would rather not touch the default templates in the long run.
>>>
>>> C) specifying templates generally in urls.py 
http://github.com/cspanring/geonode/blob/develop/src/GeoNodePy/geonode/urls.py#L20

>>>  instead of hard-coding them into views would allow users to  
>>> customize frontend designs, like switching templates, pretty  
>>> easily. That's my favorite approach so far but doing that by  
>>> myself, changing all views to that schema, would probably break  
>>> forward compatibility (seamless merging with future GeoNode  
>>> updates/fixes) of our instance too.
>>>
>>> Any other thoughts?
>>>
>>> Thanks,
>>> Christian
>>>
>>> Please be advised that the Massachusetts Secretary of State  
>>> considers e-mail to be a public record, and therefore subject to  
>>> the Massachusetts Public Records Law, M.G.L. c. 66 ? 10.
>>>
>> < /div>
>
>
>
>
> -- 
> Sebastian Benthall
> OpenGeo - http://opengeo.org
>

If you're new to git, you may find this Google Tech Talk called
"Contributing with Git" useful; it discusses topics like how to maintain
"pull-able" branches and keep up-to-date with an upstream repository.

http://www.youtube.com/watch?v=j45cs5_nY2k

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

On Mon, Nov 1, 2010 at 4:55 PM, Matt Bertrand <mbertrand@cga.harvard.edu>wrote:

>
> Hi Sebastian
>
> It's hard to tell from these brief descriptions, but I'm curious: are all
> of these additions totally custom for your needs, or could any of them be
> implemented in a general way and contributed back to the core?
>
>
> It's probably a mix of both, and I'd be happy to collaborate and contribute
> any useful parts back to the core.
>
>
> Some of these features sound like things we are working on or plan to in
> the future, and it would be great to collaborate.
>
> Please don't be shy about bringing up your needs and progress on this list,
> or joining the public developer list at geonode@opengeo.org if you want to
> discuss particular patches.
>
> On Oct 28, 2010, at 8:51 PM, Christian Spanring wrote:
>>
>> Thanks! There are a couple of good hints how to approach our issue -
>> duplicating the template dir structure and changing the template dir setting
>> seems like a good way to start. I also like the idea of havin g a fallback
>> to the default geonode.
>>
>> A colleague pointed me to the class based views discussion in Django
>> Development
>> http://docs.djangoproject.com/en/dev/topics/class-based-views/
>>
>> From what I read there, this seems to solve exactly what I'm trying to do.
>>
>> Christian
>>
>> On Oct 28, 2010, at 8:09 PM, David Winslow wrote:
>>
>> Well, we haven't done a lot of heavily customized applications, but in the
>> future I think it would be great t o have a good plan for people who want to
>> dig into Django a bit and use GeoNode as a platform for their own tools.  So
>> I'm glad to hear you're looking into it.
>>
>> In previous experiments with having an alternative theme building off the
>> core GeoNode, we had a setup where the alternate site had its own se
>> ttings.py, where early in the Python file, there was a line like:
>>
>> from geonode.settings import *
>>
>>
>> Then we modified various values as needed (INSTALLED_APPS =
>> INSTALLED_APPS + ('myapp',)).  I think this approach worked ok, but it
>> was a little cumbersome to keep the customized site up to date with the main
>> site as new pages and apps were added.  I'm not sure what a better solution
>> might be... we have started to recognize a "local_settings.py" file next to
>> the GeoNode settin gs to accommodate site-specific changes in a file that
>> won't be overwritten on updates, but I don't think that approach works well
>> if you want to add extra Django apps to the site.
>>
>> A similar approach *should* work pretty well for the urls.py though.  You
>> can just import geonode.urls in your urls.py and write "urlpatterns =
>> urlpatterns + geonode.urls.urlpatterns" to have the GeoNode URLs used as a
>> fallback if none of your URL pat terns match a request.
>>
>> Django also has a nice system for overriding templates.  If you override
>> TEMPLATE_DIRS to add an extra directory containing your customized templates
>> before the directories it already uses, then those templates will override.
>> So you would have templates in places like like
>> [/opt/mysite/geonode/login.html] and your settings would have an entry like:
>>
>> TEMPLATE_DIRS = "/opt/mysite/", \
>>
>>         & nbsp;        path_extrapolate('geonode/templates'), \
>>
>>                  path_extrapolate('geonode/maps/templates'), \
>>
>>                 path_extrapolate('django/contrib/admin/templates',
>>> 'django'),
>>
>>
>> Don't worry about the path_extrapolate function there, it duplicates some
>> path-munging functionality already present in the Django template system and
>> will probably be going away in a release soon after 1.0.  1.1, along with
>> other Pinax integration and general adoption of Django idioms, should also
>> be using the 
django-staticfiles<http://docs.djangoproject.com/en/1.2/howto/static-files/>
app
>> to provide simila r functionality for CSS and JavaScript resources, should
>> you need to override or add on to what's used in GeoNode.
>>
>> I hope this provides you some good places to start investigating.
>>
>> --
>> David Winslow
>> OpenGeo - http://opengeo.org/
>>
>> On Thu, Oct 28, 2010 at 1:44 PM, Spanring, Christian <CSpanring@mapc.org>wrote:
>>
>> Hi,
>>
>> I've started customizing a GeoNode instance and was wondering if other
>> users here are trying to do something similar. Mainly to check/discuss if
>> the path I'm going makes sense.
>>
>> The g oal is to maintain maximum forward compatibility with the main
>> GeoNode repository (painless future updates/merges). At the same time, we
>> obviously want a custom design for and add other functionality (Django apps)
>> to our GeoNode instance.
>>
>>
>> So far I've thought about a few approaches:
>>
>> A) override urls.py with my app's urls.py
>> 
http://github.com/cspanring/geonode/blob/develop/src/GeoNodePy/geonode/urls.py#L16and
duplicating code from the default GeoNode apps seems like a really bad
>> idea.
>>
>> B) modifying the default templates
>> 
http://github.com/cspanring/geonode/blob/develop/src/GeoNodePy/geonode/templates/page_layout.html#L12would
break forward compatibility at some point. That solution worked as
>> quick hack to have a basic custom design online but I would rather not touch
>> the default templates in the long run.
>>
>> C) specifying templates generally in urls.py
>> 
http://github.com/cspanring/geonode/blob/develop/src/GeoNodePy/geonode/urls.py#L20instead
of hard-coding them into views would allow users to customize
>> frontend designs, like switching templates, pretty easily. That's my
>> favorite approach so far but doing that by myself, changing all views to
>> that schema, would probably break forward compatibility (seamless merging
>> with future GeoNode updates/fixes) of our instance too.
>>
>> Any other thoughts?
>>
>> Thanks,
>> Christian
>>
>> Please be advised that the Massachusetts Secretary of State considers
>> e-mail to be a public record, and therefore subject to the Massachusetts
>> Public Records Law, M.G.L. c. 66 ? 10.
>>
>>
>> < /div>
>>
>>
>>
>
>
> --
> Sebastian Benthall
> OpenGeo - http://opengeo.org
>
>
>

Wow, I had no idea this was going on.  Sounds cool, hopefully I'll be able
to take a look at it soon.

Is there a reason you didn't use the 'fork' button on Github to create your
GeoNode fork?  It doesn't really matter, but it would be nice to have
Github's Network Graph show your work since you are using Github anyway.
 Pull requests are also useful.

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

On Sat, Oct 30, 2010 at 9:33 AM, Matt Bertrand <mbertrand@cga.harvard.edu>wrote:

> Hi,
>
> I'm working on a GeoNode customization as well.  Some of the features I
> need to add are customizable header banners for user-created maps, querying
> and highlighting selected features on the map, user defined layer
> categories, and displaying the layer tree organized by category. (
> http://github.com/mbertrand/cga-worldmap).  This is for the next version
> of "WorldMap", a web mapping platform used by Harvard's Center for
> Geographic Analysis.  We decided to use GeoNode as the basis for it since it
> already has many of the features we were hoping to include, such as data
> uploads, permission controls, style editing, etc.
>
> So far I haven't overridden any existing patterns in urls.py, but I have
> added some new ones.  I've needed to modify several of the default
> templates, and I've quite a few changes to the views and models.  I also
> added new functions to the GeoExplorer javascript file that renders the map
> view (for searching, querying, and highlighting layers).  I've been merging
> the latest code from geonode every few days, and so far the merge conflicts
> have been pretty trivial so far, though they won't necessarily continue to
> be so simple.
>
> Thanks for the useful tips!
>
> -Matt
>
>
> On Oct 28, 2010, at 8:51 PM, Christian Spanring wrote:
>
> Thanks! There are a couple of good hints how to approach our issue -
> duplicating the template dir structure and changing the template dir setting
> seems like a good way to start. I also like the idea of havin g a fallback
> to the default geonode.
>
> A colleague pointed me to the class based views discussion in Django
> Development http://docs.djangoproject.com/en/dev/topics/class-based-views/
>
> From what I read there, this seems to solve exactly what I'm trying to do.
>
> Christian
>
> On Oct 28, 2010, at 8:09 PM, David Winslow wrote:
>
> Well, we haven't done a lot of heavily customized applications, but in the
> future I think it would be great t o have a good plan for people who want to
> dig into Django a bit and use GeoNode as a platform for their own tools.  So
> I'm glad to hear you're looking into it.
>
> In previous experiments with having an alternative theme building off the
> core GeoNode, we had a setup where the alternate site had its own se
> ttings.py, where early in the Python file, there was a line like:
>
> from geonode.settings import *
>
>
> Then we modified various values as needed (INSTALLED_APPS = INSTALLED_APPS
> + ('myapp',)).  I think this approach worked ok, but it was a little
> cumbersome to keep the customized site up to date with the main site as new
> pages and apps were added.  I'm not sure what a better solution might be...
> we have started to recognize a "local_settings.py" file next to the GeoNode
> settin gs to accommodate site-specific changes in a file that won't be
> overwritten on updates, but I don't think that approach works well if you
> want to add extra Django apps to the site.
>
> A similar approach *should* work pretty well for the urls.py though.  You
> can just import geonode.urls in your urls.py and write "urlpatterns =
> urlpatterns + geonode.urls.urlpatterns" to have the GeoNode URLs used as a
> fallback if none of your URL patterns match a request.
>
> Django also has a nice system for overriding templates.  If you override
> TEMPLATE_DIRS to add an extra directory containing your customized templates
> before the directories it already uses, then those templates will override.
> So you would have templates in places like like
> [/opt/mysite/geonode/login.html] and your settings would have an entry like:
>
> TEMPLATE_DIRS = "/opt/mysite/", \
>
>                 path_extrapolate('geonode/templates'), \
>
>                 path_extrapolate('geonode/maps/templates'), \
>
>                 path_extrapolate('django/contrib/admin/templates',
>> 'django'),
>
>
> Don't worry about the path_extrapolate function there, it duplicates some
> path-munging functionality already present in the Django template system and
> will probably be going away in a release soon after 1.0.  1.1, along with
> other Pinax integration and general adoption of Django idioms, should also
> be using the 
django-staticfiles<http://docs.djangoproject.com/en/1.2/howto/static-files/>
app
> to provide simila r functionality for CSS and JavaScript resources, should
> you need to override or add on to what's used in GeoNode.
>
> I hope this provides you some good places to start investigating.
>
> --
> David Winslow
> OpenGeo - http://opengeo.org/
>
> On Thu, Oct 28, 2010 at 1:44 PM, Spanring, Christian <CSpanring@mapc.org>wrote:
>
>> Hi,
>>
>> I've started customizing a GeoNode instance and was wondering if other
>> users here are trying to do something similar. Mainly to check/discuss if
>> the path I'm going makes sense.
>>
>> The g oal is to maintain maximum forward compatibility with the main
>> GeoNode repository (painless future updates/merges). At the same time, we
>> obviously want a custom design for and add other functionality (Django apps)
>> to our GeoNode instance.
>>
>>
>> So far I've thought about a few approaches:
>>
>> A) override urls.py with my app's urls.py
>> 
http://github.com/cspanring/geonode/blob/develop/src/GeoNodePy/geonode/urls.py#L16and
duplicating code from the default GeoNode apps seems like a really bad
>> idea.
>>
>> B) modifying the default templates
>> 
http://github.com/cspanring/geonode/blob/develop/src/GeoNodePy/geonode/templates/page_layout.html#L12would
break forward compatibility at some point. That solution worked as
>> quick hack to have a basic custom design online but I would rather not touch
>> the default templates in the long run.
>>
>> C) specifying templates generally in urls.py
>> 
http://github.com/cspanring/geonode/blob/develop/src/GeoNodePy/geonode/urls.py#L20instead
of hard-coding them into views would allow users to customize
>> frontend designs, like switching templates, pretty easily. That's my
>> favorite approach so far but doing that by myself, changing all views to
>> that schema, would probably break forward compatibility (seamless merging
>> with future GeoNode updates/fixes) of our instance too.
>>
>> Any other thoughts?
>>
>> Thanks,
>> Christian
>>
>> Please be advised that the Massachusetts Secretary of State considers
>> e-mail to be a public record, and therefore subject to the Massachusetts
>> Public Records Law, M.G.L. c. 66 ? 10.
>>
>
> < /div>
>
>
>

>
> Is there a reason you didn't use the 'fork' button on Github to  
> create your GeoNode fork?  It doesn't really matter, but it would be  
> nice to have Github's Network Graph show your work since you are  
> using Github anyway.  Pull requests are also useful.

The only reason is that I didn't know about it :)  Until very recently  
I had only used internal subversion and CVS repos.

> --
> David Winslow
> OpenGeo - http://opengeo.org/
>
> On Sat, Oct 30, 2010 at 9:33 AM, Matt Bertrand <mbertrand@cga.harvard.edu 
> > wrote:
> Hi,
>
> I'm working on a GeoNode customization as well.  Some of the  
> features I need to add are customizable header banners for user- 
> created maps, querying and highlighting selected features on the  
> map, user defined layer categories, and displaying the layer tree  
> organized by category. (http://github.com/mbertrand/cga-worldmap).   
> This is for the next version of "WorldMap", a web mapping platform  
> used by Harvard's Center for Geographic Analysis.  We decided to use  
> GeoNode as the basis for it since it already has many of the  
> features we were hoping to include, such as data uploads, permission  
> controls, style editing, etc.
>
> So far I haven't overridden any existing patterns in urls.py, but I  
> have added some new ones.  I've needed to modify several of the  
> default templates, and I've quite a few changes to the views and  
> models.  I also added new functions to the GeoExplorer javascript  
> file that renders the map view (for searching, querying, and  
> highlighting layers).  I've been merging the latest code from  
> geonode every few days, and so far the merge conflicts have been  
> pretty trivial so far, though they won't necessarily continue to be  
> so simple.
>
> Thanks for the useful tips!
>
> -Matt
>
>
> On Oct 28, 2010, at 8:51 PM, Christian Spanring wrote:
>
>> Thanks! There are a couple of good hints how to approach our issue  
>> - duplicating the template dir structure and changing the template  
>> dir setting seems like a good way to start. I also like the idea of  
>> havin g a fallback to the default geonode.
>>
>> A colleague pointed me to the class based views discussion in  
>> Django Development 
http://docs.djangoproject.com/en/dev/topics/class-based-views/
>>
>> From what I read there, this seems to solve exactly what I'm trying  
>> to do.
>>
>> Christian
>>
>> On Oct 28, 2010, at 8:09 PM, David Winslow wrote:
>>
>>> Well, we haven't done a lot of heavily customized applications,  
>>> but in the future I think it would be great t o have a good plan  
>>> for people who want to dig into Django a bit and use GeoNode as a  
>>> platform for their own tools.  So I'm glad to hear you're looking  
>>> into it.
>>>
>>> In previous experiments with having an alternative theme building  
>>> off the core GeoNode, we had a setup where the alternate site had  
>>> its own se ttings.py, where early in the Python file, there was a  
>>> line like:
>>>
>>> from geonode.settings import *
>>>
>>> Then we modified various values as needed (INSTALLED_APPS =  
>>> INSTALLED_APPS + ('myapp',)).  I think this approach worked ok,  
>>> but it was a little cumbersome to keep the customized site up to  
>>> date with the main site as new pages and apps were added.  I'm not  
>>> sure what a better solution might be... we have started to  
>>> recognize a "local_settings.py" file next to the GeoNode settin gs  
>>> to accommodate site-specific changes in a file that won't be  
>>> overwritten on updates, but I don't think that approach works well  
>>> if you want to add extra Django apps to the site.
>>>
>>> A similar approach should work pretty well for the urls.py  
>>> though.  You can just import geonode.urls in your urls.py and  
>>> write "urlpatterns = urlpatterns + geonode.urls.urlpatterns" to  
>>> have the GeoNode URLs used as a fallback if none of your URL  
>>> patterns match a request.
>>>
>>> Django also has a nice system for overriding templates.  If you  
>>> override TEMPLATE_DIRS to add an extra directory containing your  
>>> customized templates before the directories it already uses, then  
>>> those templates will override. So you would have templates in  
>>> places like like [/opt/mysite/geonode/login.html] and your  
>>> settings would have an entry like:
>>>
>>> TEMPLATE_DIRS = "/opt/mysite/", \
>>>                 path_extrapolate('geonode/templates'), \
>>>                 path_extrapolate('geonode/maps/templates'), \
>>>                 path_extrapolate('django/contrib/admin/templates',  
>>> 'django'),
>>>
>>> Don't worry about the path_extrapolate function there, it  
>>> duplicates some path-munging functionality already present in the  
>>> Django template system and will probably be going away in a  
>>> release soon after 1.0.  1.1, along with other Pinax integration  
>>> and general adoption of Django idioms, should also be using the  
>>> django-staticfiles app to provide simila r functionality for CSS  
>>> and JavaScript resources, should you need to override or add on to  
>>> what's used in GeoNode.
>>>
>>> I hope this provides you some good places to start investigating.
>>>
>>> --
>>> David Winslow
>>> OpenGeo - http://opengeo.org/
>>>
>>> On Thu, Oct 28, 2010 at 1:44 PM, Spanring, Christian <CSpanring@mapc.org 
>>> > wrote:
>>> Hi,
>>>
>>> I've started customizing a GeoNode instance and was wondering if  
>>> other users here are trying to do something similar. Mainly to  
>>> check/discuss if the path I'm going makes sense.
>>>
>>> The g oal is to maintain maximum forward compatibility with the  
>>> main GeoNode repository (painless future updates/merges). At the  
>>> same time, we obviously want a custom design for and add other  
>>> functionality (Django apps) to our GeoNode instance.
>>>
>>>
>>> So far I've thought about a few approaches:
>>>
>>> A) override urls.py with my app's urls.py 
http://github.com/cspanring/geonode/blob/develop/src/GeoNodePy/geonode/urls.py#L16

>>>  and duplicating code from the default GeoNode apps seems like a  
>>> really bad idea.
>>>
>>> B) modifying the default templates 
http://github.com/cspanring/geonode/blob/develop/src/GeoNodePy/geonode/templates/page_layout.html#L12

>>>  would break forward compatibility at some point. That solution  
>>> worked as quick hack to have a basic custom design online but I  
>>> would rather not touch the default templates in the long run.
>>>
>>> C) specifying templates generally in urls.py 
http://github.com/cspanring/geonode/blob/develop/src/GeoNodePy/geonode/urls.py#L20

>>>  instead of hard-coding them into views would allow users to  
>>> customize frontend designs, like switching templates, pretty  
>>> easily. That's my favorite approach so far but doing that by  
>>> myself, changing all views to that schema, would probably break  
>>> forward compatibility (seamless merging with future GeoNode  
>>> updates/fixes) of our instance too.
>>>
>>> Any other thoughts?
>>>
>>> Thanks,
>>> Christian
>>>
>>> Please be advised that the Massachusetts Secretary of State  
>>> considers e-mail to be a public record, and therefore subject to  
>>> the Massachusetts Public Records Law, M.G.L. c. 66 ? 10.
>>>
>> < /div>
>
>

Hello folks,
anyone is working on the localization of GeoNode?
Don't know which is the best approach to this task..any idea?

Ciao
Luca
Il 30/10/2010 15:33, Matt Bertrand ha scritto:
> Hi,
>
> I'm working on a GeoNode customization as well.  Some of the features 
> I need to add are customizable header banners for user-created maps, 
> querying and highlighting selected features on the map, user defined 
> layer categories, and displaying the layer tree organized by category. 
> (http://github.com/mbertrand/cga-worldmap).  This is for the next 
> version of "WorldMap", a web mapping platform used by Harvard's Center 
> for Geographic Analysis.  We decided to use GeoNode as the basis for 
> it since it already has many of the features we were hoping to 
> include, such as data uploads, permission controls, style editing, etc.
>
> So far I haven't overridden any existing patterns in urls.py, but I 
> have added some new ones.  I've needed to modify several of the 
> default templates, and I've quite a few changes to the views and 
> models.  I also added new functions to the GeoExplorer javascript file 
> that renders the map view (for searching, querying, and highlighting 
> layers).  I've been merging the latest code from geonode every few 
> days, and so far the merge conflicts have been pretty trivial so far, 
> though they won't necessarily continue to be so simple.
>
> Thanks for the useful tips!
>
> -Matt
>
>
> On Oct 28, 2010, at 8:51 PM, Christian Spanring wrote:
>
>> Thanks! There are a couple of good hints how to approach our issue - 
>> duplicating the template dir structure and changing the template dir 
>> setting seems like a good way to start. I also like the idea of havin 
>> g a fallback to the default geonode.
>>
>> A colleague pointed me to the class based views discussion in Django 
>> Development 
>> http://docs.djangoproject.com/en/dev/topics/class-based-views/
>>
>> From what I read there, this seems to solve exactly what I'm trying 
>> to do.
>>
>> Christian
>>
>> On Oct 28, 2010, at 8:09 PM, David Winslow wrote:
>>
>>> Well, we haven't done a lot of heavily customized applications, but 
>>> in the future I think it would be great t o have a good plan for 
>>> people who want to dig into Django a bit and use GeoNode as a 
>>> platform for their own tools.  So I'm glad to hear you're looking 
>>> into it.
>>>
>>> In previous experiments with having an alternative theme building 
>>> off the core GeoNode, we had a setup where the alternate site had 
>>> its own se ttings.py, where early in the Python file, there was a 
>>> line like:
>>>
>>>     from geonode.settings import *
>>>
>>>
>>> Then we modified various values as needed (INSTALLED_APPS = 
>>> INSTALLED_APPS + ('myapp',)).  I think this approach worked ok, but 
>>> it was a little cumbersome to keep the customized site up to date 
>>> with the main site as new pages and apps were added.  I'm not sure 
>>> what a better solution might be... we have started to recognize a 
>>> "local_settings.py" file next to the GeoNode settin gs to 
>>> accommodate site-specific changes in a file that won't be 
>>> overwritten on updates, but I don't think that approach works well 
>>> if you want to add extra Django apps to the site.
>>>
>>> A similar approach *should* work pretty well for the urls.py though. 
>>>  You can just import geonode.urls in your urls.py and write 
>>> "urlpatterns = urlpatterns + geonode.urls.urlpatterns" to have the 
>>> GeoNode URLs used as a fallback if none of your URL patterns match a 
>>> request.
>>>
>>> Django also has a nice system for overriding templates.  If you 
>>> override TEMPLATE_DIRS to add an extra directory containing your 
>>> customized templates before the directories it already uses, then 
>>> those templates will override. So you would have templates in places 
>>> like like [/opt/mysite/geonode/login.html] and your settings would 
>>> have an entry like:
>>>
>>>     TEMPLATE_DIRS = "/opt/mysite/", \
>>>
>>>                     path_extrapolate('geonode/templates'), \
>>>
>>>                     path_extrapolate('geonode/maps/templates'), \
>>>
>>>                   
>>>      path_extrapolate('django/contrib/admin/templates', 'django'),
>>>
>>>
>>> Don't worry about the path_extrapolate function there, it duplicates 
>>> some path-munging functionality already present in the Django 
>>> template system and will probably be going away in a release soon 
>>> after 1.0.  1.1, along with other Pinax integration and general 
>>> adoption of Django idioms, should also be using the 
>>> django-staticfiles 
>>> <http://docs.djangoproject.com/en/1.2/howto/static-files/> app to 
>>> provide simila r functionality for CSS and JavaScript resources, 
>>> should you need to override or add on to what's used in GeoNode.
>>>
>>> I hope this provides you some good places to start investigating.
>>>
>>> --
>>> David Winslow
>>> OpenGeo - http://opengeo.org/
>>>
>>> On Thu, Oct 28, 2010 at 1:44 PM, Spanring, Christian 
>>> <CSpanring@mapc.org <mailto:CSpanring@mapc.org>> wrote:
>>>
>>>     Hi,
>>>
>>>     I've started customizing a GeoNode instance and was wondering if
>>>     other users here are trying to do something similar. Mainly to
>>>     check/discuss if the path I'm going makes sense.
>>>
>>>     The g oal is to maintain maximum forward compatibility with the
>>>     main GeoNode repository (painless future updates/merges). At the
>>>     same time, we obviously want a custom design for and add other
>>>     functionality (Django apps) to our GeoNode instance.
>>>
>>>     So far I've thought about a few approaches:
>>>
>>>     A) override urls.py with my app's urls.py
>>>     
http://github.com/cspanring/geonode/blob/develop/src/GeoNodePy/geonode/urls.py#L16
>>>     and duplicating code from the default GeoNode apps seems like a
>>>     really bad idea.
>>>
>>>     B) modifying the default templates
>>>     
http://github.com/cspanring/geonode/blob/develop/src/GeoNodePy/geonode/templates/page_layout.html#L12
>>>     would break forward compatibility at some point. That solution
>>>     worked as quick hack to have a basic custom design online but I
>>>     would rather not touch the default templates in the long run.
>>>
>>>     C) specifying templates generally in urls.py
>>>     
http://github.com/cspanring/geonode/blob/develop/src/GeoNodePy/geonode/urls.py#L20
>>>     instead of hard-coding them into views would allow users to
>>>     customize frontend designs, like switching templates, pretty
>>>     easily. That's my favorite approach so far but doing that by
>>>     myself, changing all views to that schema, would probably break
>>>     forward compatibility (seamless merging with future GeoNode
>>>     updates/fixes) of our instance too.
>>>
>>>     Any other thoughts?
>>>
>>>     Thanks,
>>>     Christian
>>>
>>>     Please be advised that the Massachusetts Secretary of State
>>>     considers e-mail to be a public record, and therefore subject to
>>>     the Massachusetts Public Records Law, M.G.L. c. 66 ? 10.
>>>
>>>
>> < /div>
>

We have been trying to use Django's built-in i18n support in our templates,
but there is only one, partial translation (to Spanish) and so changing the
language currently has little effect, and there may be places where the
English text is not marked translatable.  There is documentation on using
the i18n system <http://docs.djangoproject.com/en/1.2/topics/i18n/> and
creating 
localizations<http://docs.djangoproject.com/en/1.2/topics/i18n/localization/>
in
the official Django manual.

I would recommend creating a git checkout of the sources from
http://github.com/GeoNode/geonode/ and following the README instructions to
set up a development environment.  Since the GeoNodea project contains more
than just the Django application, you'll need to 'cd' into the proper
directory before running the Django localization tools:

$ cd src/GeoNodePy/geonode/
$ django-admin.py makemessages -l it

This will generate some dictionaries for the Italian translation in GNU
gettext's .po format.  You can edit these directly in a text editor if you
are so inclined, or there are a number of GUI tools to help with editing
them listed at the end of the Wikipedia article on
gettext<http://en.wikipedia.org/wiki/GNU_gettext>
.

If you aren't able to get a development build running I can set up the
dictionaries and you can just edit them... But you won't be able to see the
translations in context until the demo site is updated with the new
dictionaries.

Hope this helps.

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

On Sat, Oct 30, 2010 at 10:27 AM, Luca Casagrande <luca.casagrande@gmail.com
> wrote:

> Hello folks,
> anyone is working on the localization of GeoNode?
> Don't know which is the best approach to this task..any idea?
>
> Ciao
> Luca
> Il 30/10/2010 15:33, Matt Bertrand ha scritto:
> > Hi,
> >
> > I'm working on a GeoNode customization as well.  Some of the features
> > I need to add are customizable header banners for user-created maps,
> > querying and highlighting selected features on the map, user defined
> > layer categories, and displaying the layer tree organized by category.
> > (http://github.com/mbertrand/cga-worldmap).  This is for the next
> > version of "WorldMap", a web mapping platform used by Harvard's Center
> > for Geographic Analysis.  We decided to use GeoNode as the basis for
> > it since it already has many of the features we were hoping to
> > include, such as data uploads, permission controls, style editing, etc.
> >
> > So far I haven't overridden any existing patterns in urls.py, but I
> > have added some new ones.  I've needed to modify several of the
> > default templates, and I've quite a few changes to the views and
> > models.  I also added new functions to the GeoExplorer javascript file
> > that renders the map view (for searching, querying, and highlighting
> > layers).  I've been merging the latest code from geonode every few
> > days, and so far the merge conflicts have been pretty trivial so far,
> > though they won't necessarily continue to be so simple.
> >
> > Thanks for the useful tips!
> >
> > -Matt
> >
> >
> > On Oct 28, 2010, at 8:51 PM, Christian Spanring wrote:
> >
> >> Thanks! There are a couple of good hints how to approach our issue -
> >> duplicating the template dir structure and changing the template dir
> >> setting seems like a good way to start. I also like the idea of havin
> >> g a fallback to the default geonode.
> >>
> >> A colleague pointed me to the class based views discussion in Django
> >> Development
> >> http://docs.djangoproject.com/en/dev/topics/class-based-views/
> >>
> >> From what I read there, this seems to solve exactly what I'm trying
> >> to do.
> >>
> >> Christian
> >>
> >> On Oct 28, 2010, at 8:09 PM, David Winslow wrote:
> >>
> >>> Well, we haven't done a lot of heavily customized applications, but
> >>> in the future I think it would be great t o have a good plan for
> >>> people who want to dig into Django a bit and use GeoNode as a
> >>> platform for their own tools.  So I'm glad to hear you're looking
> >>> into it.
> >>>
> >>> In previous experiments with having an alternative theme building
> >>> off the core GeoNode, we had a setup where the alternate site had
> >>> its own se ttings.py, where early in the Python file, there was a
> >>> line like:
> >>>
> >>>     from geonode.settings import *
> >>>
> >>>
> >>> Then we modified various values as needed (INSTALLED_APPS =
> >>> INSTALLED_APPS + ('myapp',)).  I think this approach worked ok, but
> >>> it was a little cumbersome to keep the customized site up to date
> >>> with the main site as new pages and apps were added.  I'm not sure
> >>> what a better solution might be... we have started to recognize a
> >>> "local_settings.py" file next to the GeoNode settin gs to
> >>> accommodate site-specific changes in a file that won't be
> >>> overwritten on updates, but I don't think that approach works well
> >>> if you want to add extra Django apps to the site.
> >>>
> >>> A similar approach *should* work pretty well for the urls.py though.
> >>>  You can just import geonode.urls in your urls.py and write
> >>> "urlpatterns = urlpatterns + geonode.urls.urlpatterns" to have the
> >>> GeoNode URLs used as a fallback if none of your URL patterns match a
> >>> request.
> >>>
> >>> Django also has a nice system for overriding templates.  If you
> >>> override TEMPLATE_DIRS to add an extra directory containing your
> >>> customized templates before the directories it already uses, then
> >>> those templates will override. So you would have templates in places
> >>> like like [/opt/mysite/geonode/login.html] and your settings would
> >>> have an entry like:
> >>>
> >>>     TEMPLATE_DIRS = "/opt/mysite/", \
> >>>
> >>>                     path_extrapolate('geonode/templates'), \
> >>>
> >>>                     path_extrapolate('geonode/maps/templates'), \
> >>>
> >>>
> >>>      path_extrapolate('django/contrib/admin/templates', 'django'),
> >>>
> >>>
> >>> Don't worry about the path_extrapolate function there, it duplicates
> >>> some path-munging functionality already present in the Django
> >>> template system and will probably be going away in a release soon
> >>> after 1.0.  1.1, along with other Pinax integration and general
> >>> adoption of Django idioms, should also be using the
> >>> django-staticfiles
> >>> <http://docs.djangoproject.com/en/1.2/howto/static-files/> app to
> >>> provide simila r functionality for CSS and JavaScript resources,
> >>> should you need to override or add on to what's used in GeoNode.
> >>>
> >>> I hope this provides you some good places to start investigating.
> >>>
> >>> --
> >>> David Winslow
> >>> OpenGeo - http://opengeo.org/
> >>>
> >>> On Thu, Oct 28, 2010 at 1:44 PM, Spanring, Christian
> >>> <CSpanring@mapc.org <mailto:CSpanring@mapc.org>> wrote:
> >>>
> >>>     Hi,
> >>>
> >>>     I've started customizing a GeoNode instance and was wondering if
> >>>     other users here are trying to do something similar. Mainly to
> >>>     check/discuss if the path I'm going makes sense.
> >>>
> >>>     The g oal is to maintain maximum forward compatibility with the
> >>>     main GeoNode repository (painless future updates/merges). At the
> >>>     same time, we obviously want a custom design for and add other
> >>>     functionality (Django apps) to our GeoNode instance.
> >>>
> >>>     So far I've thought about a few approaches:
> >>>
> >>>     A) override urls.py with my app's urls.py
> >>>
> 
http://github.com/cspanring/geonode/blob/develop/src/GeoNodePy/geonode/urls.py#L16
> >>>     and duplicating code from the default GeoNode apps seems like a
> >>>     really bad idea.
> >>>
> >>>     B) modifying the default templates
> >>>
> 
http://github.com/cspanring/geonode/blob/develop/src/GeoNodePy/geonode/templates/page_layout.html#L12
> >>>     would break forward compatibility at some point. That solution
> >>>     worked as quick hack to have a basic custom design online but I
> >>>     would rather not touch the default templates in the long run.
> >>>
> >>>     C) specifying templates generally in urls.py
> >>>
> 
http://github.com/cspanring/geonode/blob/develop/src/GeoNodePy/geonode/urls.py#L20
> >>>     instead of hard-coding them into views would allow users to
> >>>     customize frontend designs, like switching templates, pretty
> >>>     easily. That's my favorite approach so far but doing that by
> >>>     myself, changing all views to that schema, would probably break
> >>>     forward compatibility (seamless merging with future GeoNode
> >>>     updates/fixes) of our instance too.
> >>>
> >>>     Any other thoughts?
> >>>
> >>>     Thanks,
> >>>     Christian
> >>>
> >>>     Please be advised that the Massachusetts Secretary of State
> >>>     considers e-mail to be a public record, and therefore subject to
> >>>     the Massachusetts Public Records Law, M.G.L. c. 66 ? 10.
> >>>
> >>>
> >> < /div>
> >
>
>