On 06/09/2010 11:57 AM, Ariel Nunez wrote:
> === 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)
>
A little more detail here would be nice; what tools do you intend to use
for these tests?
> === 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)
>
I have some docs about the Django apps that I've been sitting on for a
while; they are part of a larger developer manual that is not very
correct right now. The Django stuff is pretty recent though, I'm fairly
confident it's all correct.
All for moving the CAPRA site out of the main repository.
As mentioned earlier, I don't think we should mess with the JavaScript
too much until Andreas gets back from his vacation and finishes the
refactoring currently under way.
I would also like some more details about the changes you intend to
make; how do they affect packaging? Are they consistent with the way we
distribute things (as I understand it, there are licensing concerns such
that Ext/GeoExt/OpenLayers need to be minified separately)? Would they
result in the site using a different minified Ext for every page?
> === 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)
>
>
What's involved in adding a project profile to Pinax? Are we going to
have to convince the Pinax guys that SDI is a useful profile for their
social networking toolkit (might be a hard case to make)?
> 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.
>
I'm not against these changes, but I'd like to see a bit more info about
what's going on.
-d
