Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fail more gracefully when a query yielded no results #301

Open
Daniel-Mietchen opened this issue Apr 1, 2018 · 5 comments

Comments

@Daniel-Mietchen
Copy link
Collaborator

commented Apr 1, 2018

e.g. the "Co-occurring topics map" panel in
https://tools.wmflabs.org/scholia/topic/Q12626253
is not very useful.
Once the query has run — and Scholia thus knows (without caching, as per #67) that it had no results — the current "Unable to display result" panel should probably replaced with a statement like

This query yielded no results. You can still try to find something by modifying it.

@Daniel-Mietchen

This comment has been minimized.

Copy link
Collaborator Author

commented May 18, 2018

We looked into this today, and it seems that due to the iframe embedded from an external domain (wikidata,org), JavaScript on the Scholia end cannot access the error message to modify the display.

Pinging @lucaswerkmeister to take a look at this from the Wikidata end.

@lucaswerkmeister

This comment has been minimized.

Copy link
Contributor

commented May 19, 2018

Hm, yes, it looks like Scholia isn’t allowed to access anything in the embedded IFrames. That’s annoying.

The windows can exchange messages using window.postMessage (Scholia → WDQS via iframe.contentWindow, or WDQS → Scholia via window.parent), but for that we need to figure out which messages they can exchange that will be useful not only to Scholia, but also to other WDQS embedders.

@maxlath

This comment has been minimized.

Copy link
Contributor

commented May 21, 2018

reporting on the hacky solution I proposed in our discussions those last days:

idea

  • setting up a simple proxy running on tools.wmflabs.org which would proxy requests to the query service embed endpoint
  • from this proxy, drop all cookies and restrictive security + add CORS headers

pitfall

conclusion

yep, bubbling this issue to query.wikidata.org looks like a good solution (otherwise I can offer ideas on running the embedded page in a headless browser to get it fully rendered and edit the html before adding it to a DOM node... feeling dirty now)

@fnielsen

This comment has been minimized.

Copy link
Owner

commented May 21, 2018

In the long tem wouldn't it be better to implement the rendering on Scholia itself. This way queries does not have to be redundant.

@Daniel-Mietchen

This comment has been minimized.

Copy link
Collaborator Author

commented May 26, 2018

I opened a new ticket for doing the rendering on our end: #394 .
Would still nice to have an interim solution though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.