In my previous email I sent the wrong link for the static-files app. It should have been http://docs.djangoproject.com/en/dev/howto/static-files/
-- David Winslow OpenGeo - http://opengeo.org/ On Thu, Oct 28, 2010 at 8:09 PM, David Winslow <[email protected]> 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<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. >> > >
