Here's what I was thinking for an interim implementation of more
fine-grained JS includes:
http://github.com/dwins/geonode/commit/47f43fa54b87af8e980ec4005afd3023dce545b1
btw, if you want to play with this locally, do the following:
git remote add dwins git://github.com/dwins/geonode.git -f
# add 'dwins' as an alias for my github fork. the '-f' means "go ahead
and fetch from that repo now"
git checkout dwins/fewer-includes -b fewer-includes --track
# create a local branch (checkout -b) that you can work on that tracks
my github repo (eg, uses it for pull and merge)
There are two tricks going on here that I just didn't know about when we
wrote the current include system:
* {{ block.super }} renders the contents of the block that is being
overridden in a {% block foo %} section
* {% include "path" %} renders another template inline
So now we have four templates that do "something" for including ExtJS,
OpenLayers, GeoExt, and gxp + geonode's custom stuff, and can
selectively include whichever ones are needed in a page.
Playing with this exposed a couple of problems: lang.js doesn't
gracefully degrade when GeoExplorer is not in scope, and a number of our
other-wise non-spatial components are dependent upon GeoExt for similar
reasons. An example is the AME file upload dialog.
Anyway, just wanted to get some opinions before digging further on it.
--
David Winslow
OpenGeo - http://opengeo.org/
> Actually it's somewhat complicated to do and still support switching
> between minified and not. Ariel has some ideas for improving the
> situation (based on a Django extension:
> http://code.google.com/p/django-compress/) but I think some discussion
> is in order. In the meantime, I'll take a stab at just breaking things
> up a bit more with our current setup.
>
>
>> I think these two things are easy to fix for the more Django savvy team
>> members. If you feel like wanting to take this on and have questions, please
>> don't hesitate to contact me.
>>
>> -Andreas.
>>
>> [1] http://bit.ly/aov6xp
>>
>>
