Is there a reason you didn't use the 'fork' button on Github to
create your GeoNode fork? It doesn't really matter, but it would be
nice to have Github's Network Graph show your work since you are
using Github anyway. Pull requests are also useful.
The only reason is that I didn't know about it :) Until very recently
I had only used internal subversion and CVS repos.
--
David Winslow
OpenGeo - http://opengeo.org/
On Sat, Oct 30, 2010 at 9:33 AM, Matt Bertrand <[email protected]
> wrote:
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
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>
