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
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://github.com/sbenthall/geonode/compare/master...mapsearch> http://projects.opengeo.org/CAPRA/ticket/590 <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/636> http://projects.opengeo.org/CAPRA/ticket/667 On Tue, Jul 27, 2010 at 2:58 PM, Sebastian Benthall <seb@opengeo.org> 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
some thoughts (based only on reading of the diff, i haven't tried tests/etc) * 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 see a lot of code duplication between the map search and the layer search, especially on the JS side. * 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. * you probably didn't resolve #636 on this branch as it requires keeping "last-modified" dates on maps and there's no model changes. * it would probably be good to get out of the habit of doing bugfixes and new features in the same branch. -- David Winslow OpenGeo - http://opengeo.org/ 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 <seb@opengeo.org > <mailto:seb@opengeo.org>> 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 >
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 <seb@opengeo.org>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
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 <seb@opengeo.org> 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 <seb@opengeo.org>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
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 <seb@opengeo.org> 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 <seb@opengeo.org>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 <seb@opengeo.org>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