Closed (won't fix)
Project:
Google Search Appliance
Version:
7.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
14 Nov 2011 at 21:57 UTC
Updated:
7 May 2012 at 22:50 UTC
I'm currently implementing a D6 version of this and finding that I have to do some serious hacking to add support for oneboxes. It just doesn't support it by design.
Given how little love the D6 version of this is getting, I think it's better to shoot for support for this in D7.
Overview of what will likely need to happen:
We could also instead implement a block that performs an additional (identical) query using the onebox's frontend.
Just opening it up to discussion.
Comments
Comment #1
mpgeek commentedWe've actually begun thinking about how we might work oneboxes into the module at my institution. If anyone has more ideas, please chime in.
Comment #2
iamEAP commentedI've been working some more on this in the 6 version, but these concepts apply in 7.
The problem is that you need a separate script that runs a separate query for each onebox. You can't provide a single script and pass your own query parameters to help build the query because the appliance appends its own query parameters. i.e. you couldn't have a single generic onebox like...
/sites/all/modules/google_appliance/generic_onebox.php
And create different oneboxes like
video_onebox -> sites/all/modules/google_appliance/generic_onebox.php?foo=video
article_onebox -> sites/all/modules/google_appliance/generic_onebox.php?foo=article
Because the appliance appends its own parameters when it calls the onebox script (in particular, "query").
One solution is to make it a menu item...
/google-appliance/onebox/foo/bar
But then for each search query, you're bootrapping Drupal as many times as there are oneboxes, which I don't think is really acceptable.
Comment #3
iamEAP commentedImplementing oneboxes generically is either not possible, or prohibitively slow. The best we can do is provide a hook for altering results so that custom modules can do the extra parsing; looks like this is already there, so no action required.
I have one possible improvement that would help custom modules that do this, but I'll open a separate issue for it.
Marking: won't fix.