* putSaver: detect edit conflicts to prevent clobbering, if possible
if the server supplies an ETag, we send it back when saving, allowing
the server to detect edit conflicts and respond with 412 (cf.
https://www.w3.org/1999/04/Editing/)
caveats:
* this only kicks in after the first save, as we don't have access to
the ETag when first loading the document
* there's no recovery mechanism (e.g. resetting `this.etag` in order to
force clobbering), other than manually reloading the document
* putSaver: retrieve ETag upon initialization for clobbering protection
this addresses one of the caveats from the previous commit
(2d75cb83af) - while theoretically prone
to a race condition, it seems unlikely that saving will be triggered
before the server responds
* putSaver: simplify URI extraction
this simplifies the approach introduced in
f51f6bf774, with the purpose of removing
the fragment identifier
* putSaver: localize error message
* putSaver: switch to built-in HTTP helper
in the process, fixed ETag assignment in `#save` method (was
`this.etag`, now `self.etag`) as well as a syntax error due to a missing
closing brace
* putSaver: consolidate URI handling
Now the `tm-download-file` and `tm-save-file` messages use the hashmap
to specify variables to be applied when rendering the tiddler.
We also add a convention that the variable “filename” is used to
specify a filename for the download.
There are still some warnings about making functions in a loop, but
I’ll fix those as a separate pull request because the fixes are more
than typographic errors.
Causes the wiki to be autosaved whenever clicking “done” after editing
a tiddler. Only works with savers that support autosave. We should
probably make autosave configurable
We were re-using the `tw-save-wiki` message both for saving the current
wiki and downloading a new wiki. Now we’ll use the separate
`tw-download-file` message for downloading.
Fixes#236
It's not great, sadly. Clicking save in the browser pulls up an
unobtrusive bar at the bottom of the browser window where you can click
"save". You then get a new copy of your wiki in the downloads folder.
We don't need to encodeURIComponent at all when using blob links.
The data never goes into the dom directly, just a guid reference.
This makes saving with blobs very fast!
This should fix crashing on large wikis under chrome
see chrome bug: https://code.google.com/p/chromium/issues/detail?id=103234
This should also speed up generating the download html by a couple of seconds
it avoids repeatedly marshalling the base64 encoded href string across the sandbox boundary
it avoids some time and memory consumed by "large" dom manipulation
major remaining delay is in encodeURIComponent
TODO: consider using iconv on the server
TODO: consider async invocation of regular expressions to avoid client "lockup"
Conflicts:
core/modules/savers/download.js
