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