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

Reply via email to