Getting Under the Hood with PrizmDoc Editor

PrizmDoc Editor’s sophisticated design allows developers to embed powerful document creation and editing features into their web applications. By using a series of API calls, it gives users the ability to upload and modify DOCX files without altering the original file itself. To understand how this editing process works in practice, it’s helpful to take a closer look at what’s going on “under the hood” of PrizmDoc Editor. 

The Architecture of PrizmDoc Editor

PrizmDoc Editor consists of two main components: the Editor Control and the Editor Server. These components interact with one another and your web application. The Editor Control runs directly in the web browser. It is the primary UI for document viewing and editing within your application. Although it displays the document you’re working with, it doesn’t actually work directly with the DOCX files themselves. Instead, it sends your DOCX files to the Editor Server, which is located on the backend outside of your web application. 

After the document is sent to the Editor Server, it is converted into a proprietary internal format that the Editor Control can interact with. The Editor Server hosts the REST APIs used to import DOCX files, make edits, and export new DOCX versions of the edited document. 

For a production deployment, both document storage and database storage are used by the Editor Server throughout the workflow process. Document storage consists of a file system or S3 bucket that stores the documents themselves, while database storage houses critical metadata and other persistent information in a MySQL instance.

Your web application runs on your server between the Editor Control and the Editor Server. From that centralized position, it will need to proxy HTTP requests from the Editor Control to the Editor Server in order to facilitate your workflow.

PrizmDoc Editor Workflow

When working with documents in PrizmDoc Editor, it’s helpful to think of the typical workflow as a two-stage procedure. The first step involves document assembly, while the second is closer to the conventional editing process.

Automated Document Assembly

Once a DOCX file has been uploaded to the Editor Server, a new document resource is created with a unique document ID. This is the document that will actually be manipulated throughout the editing process. By generating a separate file, PrizmDoc Editor ensures that the original DOCX file remains unaltered for later use or reference. 

The content of this new document resource can then be dynamically adjusted before it is presented to an end-user via REST API calls. Developers can enable controls for clauses to be added programmatically so the end-user doesn’t have to go through the document manually to cut and paste various elements, which is far more prone to human error.

Document Editing Controls

After the document is assembled in the Editor Server, it’s time to create an editing session on the Editor Control side to allow end users to edit the document. Rather than downloading the new document, the viewing session renders an HTML page to facilitate editing, which preserves the integrity of the original file even as edits are made by contributors.

1. Create a New Editing Session: Once a new session ID is created, it can be embedded into the HTML, rendered, and sent to the browser for viewing and editing. Each session is auto-expiring and easy to create, so it’s best to create a new session instead of reusing previous sessions.
2. Render HTML with Editor Control: After it’s configured with the session ID, the Editor Control can render the document within your secure web application.
3. Proxy Requests from Editor Control to Editor Server: As edits are made to the document, the Editor Control uses HTTP requests to the Editor Server in order to load and save relevant data. Since it’s situated between these two elements, your web application must proxy requests between them.

The ability to create specific editing sessions makes it easy to control who has access to a document. Session configurations can be customized to restrict commenting options or assign viewing, suggesting, and editing rights permissions.

Once the session is rendered in the browser, however, editing the document is as easy as working with a conventional word processing program. PrizmDoc Editor’s UI includes a variety of toolbar and menu items for easy editing completely within a browser running on a secure web application.

Throughout the editing process, you can download a copy of the working document at any time from the Editor Server as a DOCX file. After receiving a request from the application, the Editor Server uses the current document state to render a new DOCX file and return it to the application. 

The document itself, however, continues to exist on the server and may still be edited further. Creating multiple “snapshot” copies before editing is complete is not advised because it introduces the potential for version confusion among collaborators. Once the editing process is complete and the application no longer needs to use the document resource in the Editor Server, it can be deleted using a Delete request.

Accusoft’s PrizmDoc Editor can help your application facilitate smoother, more secure workflows for contract automation and document assembly. To see for yourself how easily you can add powerful new features into your solution, try a hands-on demo today or download a free trial in an easy-to-manage Docker container.