Live example: editor in the browser
A working SumDoc editor right on the documentation page, and the whole small project that connects it: the page, the frame code, and the host.
Below is a real SumDoc editor, the same one you get in the delivery, with an ordinary contract: headings, lists, a table with dates and amounts. When the demo environment is up, you can use it right here: the document opens in your own sandbox, only you see your edits, they’re never saved anywhere, and the next visitor gets the original document. When the demo environment is down, a snapshot of the same editor sits in its place, and the frame says so underneath.
examples/a4-embedWhat this example consists of
Section titled “What this example consists of”The frame above runs the same editor and the same embedding method, but the environment is hosted by us: our demo service feeds it the document. To get the same thing working for you, you need three things — a page with a spot for the frame, the connection code, and your server with two endpoints. That’s exactly what’s shown below: a whole project that runs on its own, not excerpts from one.
Where it’s easy to get this wrong
Section titled “Where it’s easy to get this wrong”Edits arrive at your side as multipart/form-data — a single part named file. You must parse the body. If you write the raw request body into the document, form boilerplate lines get glued to the start of the file, and the document stops opening — silently, with no error in the log. The telltale sign of this on unpacking is “extra bytes at beginning”.
We’ve been caught by this ourselves, so the parsing in the example is spelled out in full, not reduced to a library call.
How this example differs from a production embedding
Section titled “How this example differs from a production embedding”| What | In this example | In your application |
|---|---|---|
| Who the user is | A guest: one identity for every visitor | Your signed-in user |
| Where the document comes from | The same demo file every time | Your file by ID |
| Where the edits go | Nowhere: the save is accepted and never written | Into your storage, through your own API |
| Permissions | Not checked | You check them, including again while the session runs |
The /fastdoc/ proxy |
Done by the same process, for brevity | Usually an nginx rule |
Everything else matches: the same editor, the same core, the same embedding method.
- How to connect it yourself, in three steps, with the required conditions — Editor in the browser.
- Where the boundaries of responsibility lie — Responsibility and security.
- Other ways to deploy SumDoc — Platforms and deployment.