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
[email protected] 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 <[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 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
