Convert project browsing facet blocks to a navigation form

I don't see any gotchas here, aside from possible apachesolr API changes of course ;-)

This is blocking launch of the new design so setting to critical.

Here's what I have so far. There are some UI issues, e.g. when searching for text string, the facet blocks default to searching by relevancy and then you can choose some other sort order. In a form the user would have to manually choose to sort by relevancy. Also, sorting by relevancy without a text string is invalid, and so the submit handler silently ignores this and reverts to sorting by title.

added some js to deal with above-mentioned UI issues.

Linking this from the Redesign project #661692: Meta issue for modules Project and Project issue tracking because this issue was tagged 'drupal.org redesign'

This patch applies but no longer works with the current project_solr.module due to the removal of the original project_solr_response_cache() function in the recent API cleanup work http://drupal.org/node/679060.

The following 2 lines should create virtually identical functionality, HOWEVER, as noted in this comment - http://drupal.org/node/679060#comment-2739610 - the execution of the apachesolr module can cause havoc with these commands depending on when they are run.

  $response = apachesolr_static_response_cache();
  $query    = apachesolr_current_query();

Be back at this in a bit.

Trying to figure out what the patch is doing - seems a little out to build a query object jsut to get the path

I've made progress on this. I've worked out which methods have been changed/renamed, which includes the two that Bill flagged up. Here is a new patch that gets us going again. At this time, I've hard-coded this to work for modules as I ran out of time (see line 580 of project_solr.module once the patch is applied).

Next up - getting this to work as it should for the various tabs and working out what form elements are needed for each D&E tab - this is now running on http://staging5.drupal.org/project/modules

Solr_Base_Query->get_path() returns something like "project/modules/xxx" which is the default Solr way of doing search I think. But we are now using like "project/modules?text=xxx". Is there any special purpose?

Well if no special purposes, here is the quick fix that can be applied on staging 5 HEAD (for search text and sorting). Please have a look.

I changed it back to "project/modules?text=xxx" in r2865.

Thanks makara.

r2871 on staging5.drupal.org/project/modules now has the form inserted below the term description copy as per the Mark Boulton prototypes. I've also added the 'Find a Module/Theme/etc' title based on parent term less the last character. Plus I've set the form to respond to arg(1) for each tab. This is going to need discussion since it is a drupal.org specific thing but it gets us moving on.

kjay:

You could use $parent_term as an argument, like what I attached.

One thing I'm concerned about is http://drupal.org/node/679060. How do we merge things like this?

This is a consolidated patch of everything from this chain working against the latest project HEAD.
There are still some fixes/improvements to be done, but at least this consolidates all of the important work from before.

This is the consolidated patch + a bunch of work to expand the navigation form to handle our project-type vocabularies.
Since expansion to handle project-type-specific vocabularies is in project.module, it seems to make sense to expand project_solr to be able to handle and utilize those elements on the browse form - in my opinion.

This may not be the final version of this - I doubt it is - but it's a working version of the navigation form and should give us a patch to review, discuss and refine.
--Bill

Streamlined version for single-select (radio) element at present. We might want to consider a "none" option, but at least this version is vastly more straightforward.

Select just makes more sense than radios, and it has the side benefit of unifying the interface.

A cleaned up version re-introducing the OR-style faceting.

There's a sorting issue that I think still needs to get sorted out (ha-ha), but this should contain most (if not all) of the other changes we discussed.

fixed some bugs in the new helper function for pulling vocabs related to project terms, removed some array_reverse() and drupal_strtolower() calls that were too d.o specific, cleaned up code comments.

A fix for text search + re-including the js.

Fix for the solr sorting for latest release and recent activity.

We ripped out the js b/c it seems relatively pointless and overly complex for the functionality it's providing. We've replaced it with a simple message if relevancy sort is selected without text. Attached is the "js" file as txt in case we need it in the future.

after further discussion about the sort by labels, made the following changes:
"Usage statistics" is now called "Most installed", "Recent activity" is now called "Last build"

other than that, committed the patch in #24 as is to HEAD.

nice work all!

setting back to active as we do still need some basic theming/CSS on the form to make it look a little nicer.

Bluebeach FF: http://img.skitch.com/20100723-ktki8h1dxqfmjtrfcxh9ghij47.png
Bluecheese FF: http://img.skitch.com/20100723-b2m4tfb4nhfam221hci8ua3y6j.png
Bluebeach Webkit (chrome): http://img.skitch.com/20100723-j73d9niq87ychj57pwnxe7xt5g.png
Bluecheese Webkit (chrome): http://img.skitch.com/20100723-tnut6u11w4dm6jj8s9yx2dbkub.png
Bluebeach IE6:
Bluecheese IE6:

Here's a patch the floats the button below, I'll try to ping someone tomorrow for help sorting out the IE issue.

Hey Mikey - I don't want to create competing patches, so can you also, when you make that fix, change "submit" and "Submit" to "search" and "Search" at the bottom of project_solr_browse_projects_form? Just something small we missed in the original patch. submit works, but search is more descriptive. If not, I'll roll a patch afterwards.
Thanks.
--Bill

committed the patch in #27 to HEAD, and deployed to drupal.org.

however, there are a couple of problems:

1. the 'Submit' -> 'Search' change mentioned in #28
2. at http://drupal.org/project/modules, the default sort order when you load the page is by 'Most installed', but the 'Sort by' select list defaults to 'Title', which is a bit confusing. we need to decide which of the two of those is actually the default sorting order, and make them agree on initial page load.

Changed "submit" to "search" for greater clarity.
Pushed the sort to draw from a variable get since that's how the browse page does it (and why the inconsistency was introduced).

key = submit
value = Search

committed #39 to HEAD, deployed to drupal.org, merged to redesign.drupal.org bzr branch.

that probably worked because of the .js file that automagically switched the sort order select box when somebody typed text into the search box. i personally felt that what that functionality was trying to do fell into the "trying to be smart, but mostly being annoying" category, so csevb10 and i decided not to include it. it's conveniently attached to #24 in case there's a compelling reason to change our mind.