If you're new to git, you may find this Google Tech Talk called "Contributing with Git" useful; it discusses topics like how to maintain "pull-able" branches and keep up-to-date with an upstream repository.
http://www.youtube.com/watch?v=j45cs5_nY2k -- David Winslow OpenGeo - http://opengeo.org/ On Mon, Nov 1, 2010 at 4:55 PM, Matt Bertrand <[email protected]>wrote: > > 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 pat terns 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/", \ >> >> & nbsp; 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]>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#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. >> >> >> < /div> >> >> >> > > > -- > Sebastian Benthall > OpenGeo - http://opengeo.org > > >
