API calls for oeo-search are always against openenergyplatform.org

[ebroda]

Description of the issue

There are three calls in the source, where the endpoint /api/oeo-search is called. All these three calls are not relative, but use the whole url: https://openenergyplatform.org/api/oeo-search?query=" + input;

This is fine on the main instance, but a problem on other instances, additionally, if these use a different or extended oeo.

Steps to Reproduce

1. https://github.com/search?q=repo%3AOpenEnergyPlatform%2Foeplatform+api%2Foeo-search&type=code

Ideas of solution

Make calls relative, I'll add a PR just afterward.

Context and Environment

• Version used: current
• Operating system: not relevant
• Environment setup and (python) version: not relevant

Workflow checklist

• I am aware of the workflow in
  CONTRIBUTING.md

[jh-RLI]

Good point, thanks. That was a practical workaround, since there’s currently no automated configuration for indexing the OEO in the lookup service. I actually added that a while back, but then had to focus on other things. I’ll need to build a complete Podman/Kubernetes solution for production this year, based on the current development setup. In this process I’ll have to deal with this issue anyway, I might wait until then to merge this PR...

[jh-RLI]

In general, it might be a good idea to move this endpoint to the “settings.py” or “.env” file to make the whole thing more modular. The frontend expects a specific format, but there may be other lookup services that work similarly.

[ebroda]

Sounds good to me.

I wasn't shure how to do such a configuration as it's in the javascript; probably some js-definition before including the file, where a var for the url ist defined.

I was also thinking about it as I replaced the endpoint with a different one; exactly the case you described as the autocomplete did not work as expected and the indexing was not included in the docker image.

[jh-RLI]

It would work that way (using some var in the JS). As i want to go more and more into the direction of "feature flags" / "service flags" where users can decide what features or services of the OEP they want to include in their own instance of the OEP i think such info is better placed into the settings.py and then pushed to the frontend via the django view (as part of the context).

Maybe an even better solution would be: As we now use vite as build tool for the JS Apps we could also use this https://vite.dev/guide/env-and-mode#node-env-and-modes

About the indexing:
There is not much missing to make it work, i even have it set uplocally ... but no time to finish it :/ Will happen during the deployment setup update i mentioned. In general, we should load the OEO into the JennaFuseki (TripleStore) and then use the API in the Indexer of the lookup service. There are alot of benefits to this, like we would always load the latest version of the Ontology availabe in the TripleStore etc.