Community
Participate
Working Groups
Created attachment 221172 [details] screenshot I've just added support for the new "remote import from Zip at a URL" feature. It is mostly working, but after it completes I get the bogus info message with [Object object] in the status area. It appears that the problem is we are trying to JSON parse some HTML text. For example, here is the fileImpl code for the "remoteImport" call: remoteImport: function(targetLocation, options) { var headerData = { "Orion-Version": "1" }; if (options.OptionHeader) { headerData["X-Xfer-Options"] = options.OptionHeader; } return xhr("POST", targetLocation, { headers: headerData, data: JSON.stringify(options), timeout: 15000 }).then(function(result) { return result.response ? JSON.parse(result.response) : null; }); }, The result.response is not json, though, it is HTML. args: Object response: "<head></head><body><textarea>{}</textarea></body>" responseText: "<head></head><body><textarea>{}</textarea></body>" status: 201 url: "/xfer/import/I/Dummy?source=http://git.eclipse.org/c/platform/eclipse.platform.git/plain/platform/org.eclipse.platform/3_1SplashPsd.zip" xhr: XMLHttpRequest __proto__: Object John theorized that this may have been broken with the switch to plain xhr. Another question is whether the client should be showing a message at all on success, but I think that's a separate issue. I suspect this kind of problem accounts for the [Object object] problems we have elsewhere (on errors, not just info)
marking M2 to keep it on radar, but this could be handled in the RC's if need be.
This HTML response on import was added here: http://git.eclipse.org/c/orion/org.eclipse.orion.server.git/commit/?id=219dc2342753ffd53b74355bf769c8a68d0b4348 Szymon do you know why this HTML response is being sent? You did this as part of switch away from Dojox.form.Uploader. Anton has since changed a lot of this so it may no longer be needed.
I can eliminate the HTML response here, but I don't know why we were doing it in the first place. The [Object] object message isn't currently appearing from what I can tell in my testing, so I think it is best to defer to post 1.0.
Created attachment 222151 [details] screenshot of failure after import the "Object object" is still happening after an HTTP import.
The steps I used to reproduce "Object object" are: 1) create a new project, Dummy 2) create a folder within that project "testing" 3) select testing folder and choose Actions->Import from HTTP... 4) paste in this URL http://git.eclipse.org/c/platform/eclipse.platform.git/plain/platform/org.eclipse.platform/3_1SplashPsd.zip 5) hit enter You'll get the zip imported but you'll also get the info message with object object. The reason this is important is that it causes "object object" to appear in the "Create new Content" use case as well. 1) Open a navigator at the root 2) Choose Sample HTML5 Site from the new content area 3) You'll get the site but you'll also get the object object problem.
There are two ways to do here: 1) Response body is empty. This is what the rest of our import POST requests do today. See: http://wiki.eclipse.org/Orion/Server_API/Transfer_API 2) Response body contains JSON representation of the file or directory that was created. This is what the response contains for the simple "create directory" API. Open 1) is the simplest thing to do at this point. For 2) it is not obvious what to return, because depending on the arguments it could be a single file that was created, or a tree of files. Unless there is something valuable a client can do with this result I think it is better to keep it empty (201 CREATED). I have implemented this option and verified that is gets rid of the funny string with Susan's steps below. It is in this branch: http://git.eclipse.org/c/orion/org.eclipse.orion.server.git/commit/?h=johna/bug389758&id=a1edb7c4a402324532b78c66cd61ec6da687d1b7 Susan I guess it is difficult for your to verify a server side fix. Do you want to try it at some point against my local running server.
(In reply to comment #6) > There are two ways to do here: > > 1) Response body is empty. This is what the rest of our import POST requests > do today. See: http://wiki.eclipse.org/Orion/Server_API/Transfer_API > > 2) Response body contains JSON representation of the file or directory that > was created. This is what the response contains for the simple "create > directory" API. > > Open 1) is the simplest thing to do at this point. For 2) it is not obvious > what to return, because depending on the arguments it could be a single file > that was created, or a tree of files. Unless there is something valuable a > client can do with this result I think it is better to keep it empty (201 > CREATED). I have implemented this option and verified that is gets rid of > the funny string with Susan's steps below. It is in this branch: > > http://git.eclipse.org/c/orion/org.eclipse.orion.server.git/commit/?h=johna/ > bug389758&id=a1edb7c4a402324532b78c66cd61ec6da687d1b7 That solution makes sense to me, the code looks good. > > Susan I guess it is difficult for your to verify a server side fix. Do you > want to try it at some point against my local running server. yep, I'll ping you
John, I tried to ping you a couple times to run the fix, but you are not online. I +1 the change from a code/API point of view, and added Ken for review, so he can look at the change with you. (or ping me tomorrow).
This was released last night: http://git.eclipse.org/c/orion/org.eclipse.orion.server.git/commit/?id=c789e2885b69a5c8936920697ff1823e4e9d7895
Verified in I20121011-2230.
