In order to get the deployment story right, we need to differentiate
between two different roles that GeoNode is assuming now, the first is
to provide a set of tools for people who need to create SDI's, for
example GeoNode used as a library to create the Capra site and the
Haiti portals; and the second role is to provide a reference
implementation of a SDI, we will call this a "skeleton project".
The combination of those two things on a single source tree makes it
harder to create and maintain projects based on GeoNode and it forces
users to either try to "extend" the GeoNode project (like the
src/capra one is doing) or just rewrite the settings.py and urls.py
from scratch (like the Haiti portals are doing).
For both of these alternatives, keeping in sync with GeoNode
development is painful and error prone, we should instead encourage
people to "use" GeoNode instead of extending it or rewriting it.
The solution to this is to make GeoNode behave like an application (in
the Django sense) and not like a project, that means not settings.py
for GeoNode and more documentation about how to integrate, as well as
having all the GeoNode specific endpoints (url paths) grouped.
Once GeoNode is an app, we should be able to create a skeleton project
using the Pinax framework and then benefitting from the whole range of
application that Pinax has already integrated and also it would mean
reaching out to the bigger Django community building out Social
Networks and Intranets to make them more aware of GIS and SDIs.
The two steps outlined above, are detailed in the following
paragraphs, in all the cases, the idea is to follow an incremental
approach without breaking the build. But how do we make it easier to
verify the build is not broken? Let's write a basic test framework.
=== 0. Test Framework ===
a. For a predefined set of GeoNode specific urls, make sure none
gives a 404. (1 day)
b. Javascript errors check. Since GeoNode uses Javascript a lot
and we are going to change the way media is included, we need sanity
tests to make sure at least there are no Javascript errors using a
command line tool. (1 day)
=== 1. Make geonode behave like an app and not like a project ===
Makes creation of new GeoNode enabled projects cleaner and easier too,
as well as updating the version of geonode in a given project during
development. Here are the substeps:
a. Disposal of geonode/settings.py. (Move them all to
capra/settings, group together the ones we created and delete the
unused ones.) (1 days)
b. Getting all of the capra specific things out of the GeoNode
source tree. (1 days)
c. Fixing the static media handling: Use existing apps to serve
media, compress css and javascript to avoid duplication and avoid the
current high load times because of the number of files in deployment.
Includes hooking up jstools with django-compress. (2 days)
d. Modify geonode/urls.py so it is possible to include the
following line in the project urls.py:
(r"^geonode/", include("geonode.urls")),
Or hook it up to the root of the server path if we want. (1 day)
e. Documenting the proper way to include the GeoNode app in a
project, including the needed settings (i.e. GEOSERVER_URL), the way
to run a jetty instance with just GeoServer/GeoNetwork, GeoNetwork
setup, etc. (1 day)
=== 2. Integration with Pinax ===
This will let us use the built-in Profile, Accounts (Sign up, Password
Reset, TimeZones, Per user language settings), Groups (optional),
Static media handling and Notifications.
a. Integrate Pinax templates and GeoNode templates (2 days)
b. Create the sample project skeleton -loosely based on the Capra
project and using Pinax theme- (2 days), after that is done we should
be able to create a new geonode like this:
.. code-block::bash
mkvirtualenv mysite-env
pip install Pinax
pinax-admin setup_project -b geonode mysite
cd mysite
./geoserver/startup.sh #probably just calling jetty
./manage.py runserver
c. Create the geonode_profile app based on the specs and use it to
replace the basic_profiles up bundled up with Pinax. (1 day)
As you may suppose, the "tongue-in-cheek" estimations presented in the
document actually mean between 3 and 4 weeks of development time.
If I get positive feedback, I'll start right away on the step 0 to try
and have it done before leaving New York, possibly borrowing some time
from someone with experience in testing Javascript with command line
tools.
Regards,
Ariel.
