Community
Participate
Working Groups
As wrote in Bug 339898, comment 3: The Orion compare editor needs three resources right now. The content of the left, right input and the unified diff (to mark changes in the UI). Right now URIs of the resources are just crafted in the compare code. In the nearest future I would expect that the Diff representation will look like this [1]: - location (URI) of the left side content - location of the right side content - location of the Diff itself - the Diff content When we add more compare services (like the service for comparing files), we just need to make sure that they use the same representation i.e. [1] for their Diff resources. If it is true, the compare UI will just render it, no matter what service provides the Diff. In other words, if we have Diff URI e.g. http://myserver/myDiff and it returns a Diff representation like in [1], http://orion/compare.html#http://myserver/myDiff would work showing a proper compare UI.
Libing, do you think you will be able to consume a multipart response[1] returned for GET <diff uri>? E.g.: Content-type: multipart/alternative; boundary="===" Content-Type: json; <json data containing URIs for: left side content, right side content, diff itself> === Content-Type: text/plain; <the diff content> [1] http://www.w3.org/Protocols/rfc1341/7_2_Multipart.html
Tomasz , I dont think multipart handling will be a a big issue. But there is an interesting point here about the left side URI.Here is a specific work flow I was just about to ask: 1.Modify a file and save 2.Go to git status page and stage that file. 3.Compare that file using compare editor 4.Modify that file in the left side of the compare editor. 5.Save. I step 3 , we are comparing index VS HEAD , what is the left side URI ? will it be the URI on index? if yes , how can I save it ?
(In reply to comment #2) > I step 3 , we are comparing index VS HEAD , what is the left side URI ? will it > be the URI on index? if yes , how can I save it ? If I wanted to save a left/right side of the compare editor, I would expect the compare editor to call PUT on left/rightContentURI. For instance, if two files are being compared, URIs of the left/right sides should be something like http://host/file/[path] and pressing 'save' on the compare editor should call PUT http://host/file/[path] passing the content to save in the body.
(In reply to comment #3) > (In reply to comment #2) > > I step 3 , we are comparing index VS HEAD , what is the left side URI ? will it > > be the URI on index? if yes , how can I save it ? > > If I wanted to save a left/right side of the compare editor, I would expect the > compare editor to call PUT on left/rightContentURI. > For instance, if two files are being compared, URIs of the left/right sides > should be something like http://host/file/[path] and pressing 'save' on the > compare editor should call PUT http://host/file/[path] passing the content to > save in the body. OK , then I think the parameter on PUT should be returned from the the DIFF service , instead of being crafted .
(In reply to comment #2) > I step 3 , we are comparing index VS HEAD , what is the left side URI ? will it > be the URI on index? As long as the URI gives you the expected result (i.e. file content) you should not be interested in it's format. > if yes , how can I save it ? In the case you mentioned (step 3), the left side content is taken from <index URI> and the right side from <HEAD URI>. None of them can be used to save file content. As Szymon mentioned, you should be able to recognize/remember the <file URI> of the file being compared and use it to save it. However, you should keep in mind the the content from <index URI> may be quite different from the one in working tree (<file URI>).
(In reply to comment #5) > (In reply to comment #2) > > I step 3 , we are comparing index VS HEAD , what is the left side URI ? will it > > be the URI on index? > > As long as the URI gives you the expected result (i.e. file content) you should > not be interested in it's format. > > > if yes , how can I save it ? > > In the case you mentioned (step 3), the left side content is taken from <index > URI> and the right side from <HEAD URI>. None of them can be used to save file > content. As Szymon mentioned, you should be able to recognize/remember the > <file URI> of the file being compared and use it to save it. However, you > should keep in mind the the content from <index URI> may be quite different > from the one in working tree (<file URI>). Tomasz , I think in this case we may want to make the left side read only otherwise we don't know where to save it.
In addition to comment 7 , I just want to make sure : 1.The compare.html format should be something like : compare.html#fileURIOnLeft?fileURIOnRight , where fileURIOnRight represents a file that is always read-only. 2.We should also know if the fileURIOnLeft is read-only(from the response of diff? or from hash when the html is called?) I think we should only edit a file from the working directory , otherwise it should be read-only and the compare editor works as a viewer.
(In reply to comment #7) > Tomasz , I think in this case we may want to make the left side read only > otherwise we don't know where to save it. True. Actually both sides should be read only, you're not allowed to saved directly to HEAD. Please ignore the second part of comment 5. If the editor or its part (left or right) is not is read-only mode, we can try to do PUT on the URI you used to retrieve the content. Of course, it doesn't mean the request will always succeed. This approach, failing on PUT when not allowed, will let us to continue the work even without having bug 340439 fixed. (In reply to comment #8) > In addition to comment 7 , I just want to make sure : > 1.The compare.html format should be something like : > compare.html#fileURIOnLeft?fileURIOnRight , I would go with compare.html#diffUri, where GET on the "diffUri" will give you a response similar to the one from comment 1: URIs for both side contents, the diff itself.
(In reply to comment #9) > (In reply to comment #7) > > Tomasz , I think in this case we may want to make the left side read only > > otherwise we don't know where to save it. > > True. Actually both sides should be read only, you're not allowed to saved > directly to HEAD. Please ignore the second part of comment 5. > > If the editor or its part (left or right) is not is read-only mode, we can try > to do PUT on the URI you used to retrieve the content. Of course, it doesn't > mean the request will always succeed. This approach, failing on PUT when not > allowed, will let us to continue the work even without having bug 340439 fixed. > > (In reply to comment #8) > > In addition to comment 7 , I just want to make sure : > > 1.The compare.html format should be something like : > > compare.html#fileURIOnLeft?fileURIOnRight , > > I would go with compare.html#diffUri, where GET on the "diffUri" will give you > a response similar to the one from comment 1: URIs for both side contents, the > diff itself. I think we should be OK using this format : the URI already includes the file 1 and file 2 info , as we discussed yestoday.
Fixed with http://git.eclipse.org/c/e4/org.eclipse.orion.server.git/commit/?id=20b5406ca4514c034953118461c88e4af755c671. Libing, please let me know if you have any problems with consuming the new output.
Hi, Tomasz , I think I misunderstood what you mentioned as multipart response. I thought it will be a json response and one of the attributes will be the diff text. I am using dojo.xhrGet but unfortunately it does not support multipart format(or is there any other API supporting this? I don't know yet) Is it possible to change the response just as json?
(In reply to comment #12) > Hi, Tomasz , I think I misunderstood what you mentioned as multipart response. > I thought it will be a json response and one of the attributes will be the diff > text. Have you ever read comment 1? > I am using dojo.xhrGet but unfortunately it does not support multipart format(or > is there any other API supporting this? I don't know yet) FileHandlerV1[1] also returns a multipart response. John, how does the client handle this kind of response? Could you point us to a piece of code which does that? [1] org.eclipse.orion.internal.server.servlets.file.FileHandlerV1.handleMultiPartGet(HttpServletRequest, HttpServletResponse, IFileStore)
Added handlers for "?parts=diff" and "?parts=uris". The former returns a diff only, the same response which had been returned before the change made in comment 11. The later returns JSON object containing URIs with files content. Combing the parts (eg. "?parts=diff,uris") or skipping them will result in a multipart response. See http://git.eclipse.org/c/e4/org.eclipse.orion.server.git/commit/?id=aa3873b2b06371f47d790becbfb1f282a5f55d5b.
Just verified , it meets the client side need and gives more flexibility on the client side to handle it.
