Well, we haven't done a lot of heavily customized applications, but in the
future I think it would be great to 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<http://docs.djangoproject.com/en/1.2/howto/static-files/>
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 <[email protected]>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#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.
>
