mmisw / orr-portal

ORR Frontend component
Apache License 2.0
8 stars 5 forks source link

ISSUE-172 Update YASGUI to Triply.cc version #173

Open lewismc opened 4 years ago

lewismc commented 4 years ago

Hi @carueda this PR makes a start at the upgrade. It looks pretty good. It's been interesting learning more about the YASGUI and associated API's. Loads of interesting things we can do here. Also, I hope that whatever we do here, we can re-use when we decide to implement the new GUI.

As you can see, I'm going to add multiple tabs which will provide example SPARQL queries to the user. I still have some work to do but you will get the idea.

Do you know how to get around the CORS issue with regards to executing the query against COR?

carueda commented 4 years ago

Do you know how to get around the CORS issue with regards to executing the query against COR?

Can you elaborate? Traditionally the setup of the agraph proxypass in the MMI instance but I'm pretty sure also in the COR, has included CORS enabling AFAICR. Maybe it's not actually working in COR? If you are testing things locally can you retry against MMI ORR sparql endpoint as a way of quick verification?

lewismc commented 4 years ago

Can you elaborate?

Yes see screenshot below. I'm experiencing this when running on this branch and executing gulp try_dist --localConfig --base=/orrportal/ then navigating to the http://localhost:9001/orrportal/sparql/

Screen Shot 2020-07-25 at 2 17 43 PM
carueda commented 4 years ago

@lewismc I figured this out -- It is a YASQUI issue, which I now remember I mentioned to you a while ago:

YASGUI stores a bunch of stuff in local storage (which is not necessarily bad per se), but some of the saved settings start to take precedence over others, in particular the desired SPARQL endpoint!!!

Look at this while reproducing the error:

2020-07-25_1728

As shown at the top, the configured endpoint is http://cor.esipfed.org/sparql. However, as shown in the console, the error refers to https://mmisw.org/sparql !!

Look at the local storage:

2020-07-25_1731

I've highlighted in yellow entries still referring to https://mmisw.org/sparql (surely from previous local testing against MMI, which might be also your case), and with green some other entries having http://cor.esipfed.org/sparql.

So, kind of messy IMO.

I should probably have reported this long ago to YASGUI but it seems I didn't have the time (want to go ahead?).

The workaround is "simply" to remove the YASGUI entries from local storage (well, at least the ones referring to endpoints).

I just did that and the query against COR completes just fine:

2020-07-25_1736

lewismc commented 4 years ago

Thanks for the review here @carueda I would like to cover this at the next COR meeting... why? Because I would like to pre-populate some tab's with example queries. I would like to think about how we do that in a 'generic' manner which could benefit all ORR deployments.