Webstrates A research prototype enabling collaborative editing of websites through DOM manipulations.

Prototyping

When creating a webstrate that’s based on another webstrate, we call it prototyping. This can be done either through the HTTP API or the JavaScript API, which we will cover below.

Prototype from a ZIP

To overwrite the existing webstrate with one from a ZIP archive (like one downloaded with ?dl), you can prototype from a file:

webstrate.newFromPrototypeFile([webstrateId])

Calling the above will open a file selector dialog that accepts ZIP files and returns a promise. The ZIP file will then be extracted to the specified webstrateId. If the webstrate already exists or isn’t empty, the promise will be rejected. If no webstrateId is specified, the current webstrateId will be assumed.

Prototype from a URL

To prototype from a URL:

webstrate.newFromPrototypeURL(url, [webstrateId])

The above will download the file (or page) from the specified URL and prototype it to the specified webstrateId. If the webstrate already exists or isn’t empty, the promise will be rejected. If no webstrateId is specified, the current webstrateId will be assumed.

When using webstrate.newFromPrototypeFile(), the same rules apply as with the HTTP API, so remember to add ?dl to the end of the URL if prototyping from another webstrate.

When copying a webstrate that the copier doesn't have permissions to modify (read), one of two things will happen:
  • If the user is logged in, the read-write permissions are added to the permissions list of the copied webstrate. Note that the original permissions persist in the copy.
  • If the user isn't logged in, the permissions will be wiped from the webstrate, so the webstrate uses the default permissions.
Note that it's not possible to copy a webstrate in which the user doesn't have read permissions, either explicitly in the data-auth, or implicitly by falling back to default permissions.

Restoring a webstrate

Webstrates has fine-grained versioning control, saving every keystroke in the operations history. Restoring a document to a previous version can be done either through the HTTP API:

  • GET on http://<hostname>/<webstrateId>?restore=<versionOrTag> restores the document to look like it did in version or tag <versionOrTag> and redirects the user to /<webstrateId>. This will apply operations on the current verison until the desired version is reached and will therefore not break the operations log or remove from it, but only add additional operations.

Or through the JavaScript API by calling webstrate.restore(versionOrTag, fn). fn is a function callback that takes two arguments, a potential error (null on success) and the new version:

webstrate.restore(versionOrTag, function(error, newVersion) {
  if (error) {
    // Handle error.
  } else {
    // Otherwise, document is now at newVersion, identical to
    // the document at versionOrTag.
});

webstrate.restore returns a new version, because when restoring a document, the history is not actually reverted, rather appended to. A bunch of operations is applied to the document to make the document identical to what it was at the requested version.

To find out more about why and how it works, check out the Versioning page.

Deleting a webstrate

Deleting a webstrate can exclusivel be done through the HTTP API:

  • GET on http://<hostname>/<webstrateId>?delete will delete the document and redirect all connected users to the server root. The webstrate data including operations history, tags, assets, etc. will all be completely and unrecoverably deleted.

This versioning can be accessed through the HTTP API, i.e. ?ops and accessing previous versions, see also tags for marking versions with memorables names.