Community
Participate
Working Groups
In compare-container.js:setEditor(), near the end, the URI of the file source has the query trimmed and is fetched using the FileClient (due to the #setInput at the end of the function). Trimming the query causes problems because I'm serving content using my own URI supplied by a DiffProvider. Useful information is in the query string. Refetching the content causes a problem because my URI doesn't match the standard lookup service, and I'm not registering my service (because I'm trying to keep my client as trivial as possible). I'm able to work around these problems by setting '?readonly=true' on the initial query URI, but it's a bit of a hassle.
I am about to release a new version of compare container, which will accept different options when you construct the widget. I will consider this bug together.
I'm going to switch to content URIs that don't require query parameters. This work item is still valid, but not important for my investigation.
(In reply to comment #2) > I'm going to switch to content URIs that don't require query parameters. This > work item is still valid, but not important for my investigation. The trimming was indeed a work around at the moment. We had to understand a file name from the URL but some times a file URL in git history contains "?parts=body". Eventually we should ask the diff Provider or name resolver to give back a file name by URL. In Orion we have file service to give back file meta data. But RTC may have its own way to know a file name. This means the consumer has to tell the compare widget how to resolve file name bu URL.
The compare widget has been improved a lot so this issue no longer exists.
