> > 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. >
Generally, I'm +1 this direction in the long run. Could it be broken into more than one application? I wonder if functionality could be split in ways that would encourage more efficient community reuse. > === 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). This sounds like a good thing for the project to me. But I see Dwins' comment. Info on this? Introducing a new framework into the build is kind of a big deal. I know we've looked into different ones in the past; it's worth sharing the knowledge. 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. > So, though I just said "cool" in response to your talking about working on this immediately in IRC, after reading this thread and thinking it over I think it would be a good idea to get on the same page about this some more before rushing forward on it. I think it's all great ideas but we've had problems in the past with sweeping architecture changes without discussion among the developers, because different people have different levels of understanding of the huge and varied stack. The other issue is that while this is all relevant to the 1.0 release which is our top priority right now, it's not strictly necessary for it. Unfortunately, this project has had to do a lot of things _wrong_ in order to meet deadlines over the course of its development. A lot of the weirdness of the current architecture is due to that (we can talk some time about the all-static-HTML-and-JavaScript version of the 'web app' that was our Round 1). I look forward to our fixing these things as much as anybody but what's more important right now is being feature-complete for 1.0, for which a lot of tickets already exist. As decisions fall out of this discussion, we'll make more tickets and assign them priority as appropriate. Personally, I hope we can make time for a lot of these changes in time for our 1.0 release, but I'm not in a position to judge until there is weighing in from the perspective of JavaScript development, building alongside the Java stack, etc. -- Sebastian Benthall OpenGeo - http://opengeo.org
