Ok, this stuff is all in. Thanks to David for his help. Just note: these changes add a last_modified field to the Map model, so you'll have to update your django databases.
On Tue, Aug 3, 2010 at 7:36 PM, Sebastian Benthall <[email protected]> wrote: > Ok. "New Maps" work and MapGrid removal are done in the branch. Bug fix > is in master as its own commit. > > http://github.com/sbenthall/geonode/compare/master...mapsearch > > <http://github.com/sbenthall/geonode/compare/master...mapsearch>As we > discussed earlier today, I'll work on merging in Tenzo's new template work > next. > > Since http://projects.opengeo.org/CAPRA/ticket/575 is looming and the fate > of this map search code depends on user feedback and design on unified > search, I think the refactor should wait for now. > > > On Tue, Aug 3, 2010 at 11:16 AM, Sebastian Benthall <[email protected]>wrote: > >> Thanks for the quick review. >> >> >>> * we have a separate search for maps vs. layers? I don't remember >>> discussing this approach, but it seems a little odd. I'd expect a single >>> search page, maybe with checkboxes for different types of content if we want >>> to allow users to search "just maps" or whatever. >>> >> >> I agree that this is the way things should be ultimately. However, I >> wasn't confident that combined search could be delivered in time for the >> deadline, so in design review discussions we settled on an interim solution. >> >> If you think that combined search could be implemented quickly, then I >> definitely think that would be an improvement, but at this point it feels >> like scope creep to me. >> >> >>> * i see a lot of code duplication between the map search and the layer >>> search, especially on the JS side. >>> >> >> Very true. >> >> I considered refactoring it to avoid code duplication, but wasn't sure if >> it would be worth it if we were going to collapse the searches back into one >> view in the near future. >> >> >>> * should we be getting rid of the old MapGrid.js? i am especially >>> concerned about having MapGrid and MapTable as sister classes in the >>> JavaScript hierarchy - that seems to just invite mixups. >>> >> >> Good point. Will do. >> >> >>> * you probably didn't resolve #636 on this branch as it requires keeping >>> "last-modified" dates on maps and there's no model changes. >>> >> >> Good point. Oversight on my part. >> >> >>> * it would probably be good to get out of the habit of doing bugfixes >>> and new features in the same branch. >>> >> >> Yeah, true. Would it be best to make that commit separately so that it >> can be more easily tracked and then merge that change to >> github/geonode/master back to my branch? >> >> I this rule gets especially important if we're going to be pulling >> individual bug fixes from a development branch to a more stable release >> branch. >> >> >>> >>> >>> On 08/02/2010 06:07 PM, Sebastian Benthall wrote: >>> >>> I think these are good to go now. I'm hoping to commit these by the end >>> of tomorrow; a review would be great. >>> >>> http://github.com/sbenthall/geonode/compare/master...mapsearch >>> >>> Tickets: >>> Map tab and search: >>> http://projects.opengeo.org/CAPRA/ticket/590 >>> http://projects.opengeo.org/CAPRA/ticket/636 >>> >>> Broken search button on index >>> http://projects.opengeo.org/CAPRA/ticket/667 >>> >>> On Tue, Jul 27, 2010 at 2:58 PM, Sebastian Benthall <[email protected]>wrote: >>> >>>> Just wanted to give a heads up on some work I've been doing on the Maps >>>> tab and search workflows and invite reviews. >>>> >>>> http://github.com/sbenthall/geonode/commits/mapsearch >>>> >>>> The changes are covered by >>>> http://projects.opengeo.org/CAPRA/ticket/636 >>>> >>>> The gist was: make Maps searchable with a similar user interaction >>>> workflow and views as the Data tab. >>>> >>>> Work on this is mostly done. Big thanks to Luke, whose Data code >>>> formed the foundation of it all, and Ariel, who told me how to do the >>>> keyword filter query in Django. >>>> >>>> The main known thing that remains (besides a bug or two which I intend >>>> to leave to the end because they can be hammered out after the beta >>>> release) >>>> is integration with what's in the works regarding Map points of contact. >>>> From the user's perspective, this amounts to having the Contacts column >>>> contain the names of a Map's point of contact, with a link to that person's >>>> profile. >>>> >>>> -- >>>> Sebastian Benthall >>>> OpenGeo - http://opengeo.org >>>> >>>> >>> >>> >>> -- >>> Sebastian Benthall >>> OpenGeo - http://opengeo.org >>> >>> >>> >> >> >> -- >> Sebastian Benthall >> OpenGeo - http://opengeo.org >> >> > > > -- > Sebastian Benthall > OpenGeo - http://opengeo.org > > -- Sebastian Benthall OpenGeo - http://opengeo.org
