Hello folks, anyone is working on the localization of GeoNode? Don't know which is the best approach to this task..any idea?
Ciao Luca Il 30/10/2010 15:33, Matt Bertrand ha scritto: > 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 >>> <http://docs.djangoproject.com/en/1.2/howto/static-files/> 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] <mailto:[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> >
