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