When a constructor is spied using Sinon it is wrapped by a proxy
function, which calls the original constructor when invoked. When "new
Foo()" is executed a "Foo" object is created, "Foo" is invoked with the
object as "this", and the object is returned as the result of the whole
"new" expression.
Before Sinon 4.1.3 the proxy called the original constructor directly
using the "thisValue" of the spied call; "thisValue" was the object
created by the "new" operator that called the proxy. The proxy assigned
"thisValue" to "returnValue", so it was also the value returned by the
proxy and, in turn, the value returned by the whole "new" expression.
Since Sinon 4.1.3 (see pull request 1626) the proxy calls the original
constructor using "new" instead of directly. The "thisValue" created by
the outermost "new" (the one that called the proxy) is no longer used by
the original constructor; the internal "new" creates a new object, which
is the one passed to the original constructor and returned by the
internal "new" expression. This object is also the value returned by the
proxy ("returnValue") and, in turn, the value returned by the whole
outermost "new" expression.
Thus, now "returnValue" should be used instead of "thisValue" to get the
object created by the spied constructor.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The helper funtion did not handle the response correctly and basically
only returned the last share with tags.
This is a simple rewrite. That is still understandable. Loops maybe more
than strictly required. But preformance is not the issue here.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
As "singleFileUpload" is used the "add" callback (which in turn calls
"addFileToUpload") will always be called with a single file. Therefore
there is no need to iterate over the files (and it is not done in the
other callbacks either, so this aligns the code with the rest of the
callbacks).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
There is no need to store the file name, as the "data" parameter given to
all the callbacks provides a "files" attribute with all the files that
the callback refers to; moreover, it will always be a single file due to
the use of "singleFileUploads" in the jQuery File Upload plugin.
This also fixes the loading icon not disappearing when several files were
uploaded at once. "singleFileUploads" causes the "add" callback to be
called once for each file to be uploaded, so "fileName" was overwritten
with the name of each new file in the upload set; when "fileName" was
later used in the "done" callback to find the file in the list whose
loading icon replace with the MIME type icon "fileName" always had the
name of the last file, and thus its icon was the only one replaced.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The "done" and "fail" callbacks both update the item for the uploaded
file using "setFileIcon". "setFileIcon" updates the contents of the
"<li>" element for the file, but the "fail" callback was giving
"setFileIcon" an element generated by the template, so the resulting
HTML contained a "<li>" element nested in another "<li>" element.
However, generating the HTML is better done through a template, so the
template now receives the icon to show in order to be used by a
successful upload and a failed one, and "setFileIcon" was changed to
"updateFileItem".
Note that the mimeTypeUrl does no longer need to be escaped, as
Handlebars templates escape the needed characters automatically.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When the "fail" callback is called, "errorThrown" is a property of the
data object instead of a parameter.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Tobia De Koninck
Daniel Calviño Sánchez
Nextcloud bot
Morris Jobke
Robin Appelman
Roeland Jago Douma
Roeland Jago Douma
Joas Schilling
Marin Treselj