To use bbop_managers for handling communication and callbacks

[tmushayahama]

@kltm @cmungall In the process of converting "object" built requests to using bbop_managers for handling requests. I blindly did the setup according to docs, but I get a CORS error

Further screenshots and code will appear, if needed, but a quick glance, it seems like json.wrf query param is missing on the request generated by bbop-manager-golr .

[tmushayahama]

@kltm I think I found it, but I don't know if it solves it. I added engine.use_jsonp(true) . It is very hidden, I think it should be added to documentation of manager-golr

Now I am on this issue, I created it here https://github.com/berkeleybop/bbop-manager-golr/issues/9

So far I hustled by partially using the manager and did this to build the right q param. It works, but ehhh!!

buildQ(str) {
    let manager = new golr_manager(gserv, gconf, engine, 'async');

    manager.set_comfy_query(str);
    return manager.get_query(str);
}

//then
requestParams.q = buildQ('cholesterol')

[kltm]

@tmushayahama I'm honestly not even sure the managers are designed to emit quite what you want; the unit tests should be checked. As well, I'm not entirely sure what your process is for making strings, then decoposing them again it to get through any limits that might be hit with GET limits (although that might not be an issue in this case). I believe that the server should be setup to use CORS, we might want to just fix things up to use that.

[vanaukenk]

@tmushayahama - I'm not sure of the correct status for this ticket. Please go ahead and close if this issue is resolved. Thx.

[vanaukenk]

@tmushayahama - please feel free to close this ticket, if these issues have been resolved. Thx.

[tmushayahama]

@kltm @vanaukenk @lpalbou @cmungall before closing this, any way the neo autocomplete can be an API (then ideally a web component :) ). I think some things should be hidden especially the weights etc more info on newly created ticket https://github.com/geneontology/minerva/issues/236

[kltm]

@tmushayahama I think there is something to be said for either having NEO available in biolink for a simplified API or having a more custom-fitted bbop-manager subclass for it (although weights are purely optional, I'm not sure why one would use those). I think that having multiple API wrappers for Solr is likely the wrong way to go.