Documents Application

Summary

The Documents Library JavaScript support is included in a Visual Studio solution with source code that is located in your machine at this location:

[LEADTOOLS_INSTALLATION]\Examples\JS\Documents\DocumentViewer\DocumentViewer.sln

The solution contains multiple client-side projects with HTML, CSS, and JavaScript user interface code. These projects should run on any HTML5-supported desktop or mobile web browser. Both a Microsoft TypeScript version and compiled JavaScript version is included for each client. Full source code is included and can be modified to suit your application needs.

The remaining project, DocumentsService, is an ASP.NET Web API application project that serves as the server-side code for the previously-mentioned clients. It can be run on a Windows machine, and a separate DocumentsServiceJava can be run on Windows or Linux machines. With either service, all endpoints are configured to the ~/api/* directory.

Leadtools.Documents.js serves as the JavaScript proxy for the .NET Documents Library classes. This proxy hides the web service implementation and exposes the Documents Library as a native JavaScript library containing classes and objects. Your application should use these classes to interact with the server code.

To start using the DocumentViewer, simply open DocumentViewer.sln in Visual Studio, select the startup projects (the client and server projects to run) and hit F5. This will run the document viewer using IIS Express, which is most suitable for development. You can set breakpoints in the client JavaScript code or in the server C# code as needed.

At any time, you can right click the project in Solution Explorer and select Deploy to host the application in IIS on the same machine, a separate machine or in the cloud. Refer to this article in MSDN for more information.

During development or deployment, you may want to modify local.config (or the parent web.config) to update the server side options such as the cache directory, OCR engine type or Raster Codecs options if needed.

The DocumentFactory class contains the following properties that are need for setting up the client to access the server code:

Member	Value
ServiceHost	The URL to the service host. The default value is null, which means to use the same host as the client (for example, `http://localhost:port` for IIS Express, `http://localhost` in general, or `http://current_ip_address`). When deploying the service to another machine or into the cloud, it is recommended to keep the server and client code on the same host. Otherwise, be sure to configure the implementation of CORS in the service.
ServicePath	The path from the host to the application root. The default value is null, which means to use the path to the client. By default, the project is set up such that api endpoints directory (`../path/to/application/api`) is only slightly different from the directory of the client (`../path/to/application/app`). This means that the value of ServicePath will be `../path/to/application/app`. However, the ServiceApiPath property exists so that this property need not be changed if the client and server reside mostly along the same path.
ServiceApiPath	The path to the api endpoints of the service. The default value is null As explained above, the project is set up such that api endpoints directory (`../path/to/application/api`) is only slightly different from the directory of the client (`../path/to/application/app`). This means that the value of ServicePath will be `../path/to/application/app`. To make the proper adjustment over to the `api` folder, the DocumentViewer client sets this to `../api`. This way, ServicePath does not need to be set to an explicit value.
ServiceUri	Gets the full URL of the service, concatenating ServiceHost (or the client host if null), ServicePath (or the client path if null), and ServiceApiPath. This means that if no values are set, ServiceUri will be the full path to the client; if we change the ServiceApiPath to `../api`, the ServiceUri will become the default location of the api namespace. The ServiceUri, when built, will strip out unneeded trailing slashes.

The JavaScript application that uses the LEADTOOLS Documents library must set the values in DocumentFactory at the beginning of the program if required. These values are global and can be accessed from any part of the application. The various classes, objects and commands of the JavaScript proxies will use these values when needed to make calls to the web service and obtain results. For example, you can start using the LoadFromUri to create a new Document object from a URL and start using it in your application.

Documents Service Routing and Data Structures

Many methods in lt.Documents of Leadtools.Documents.js will send requests to the web service to execute code on the server. Generally, DocumentFactory.ServiceUserData can be used to send additional data with any of these requests. DocumentFactory.PrepareAjax also allows requests to be modified before sending.

To see exactly what other properties will be sent with each request, you can check the source code of the .NET or Java service. The .NET Web Api service includes a documentation module that allows developers to view the API documentation by running the service and navigating to [service-uri]/help. For example, the documentation for the most recent online version of the online DocumentViewer's .NET service is located at https://demo.leadtools.com/JavaScript_DocumentViewer_Service/help.

Developers can also view these same request and response classes by opening the TypeScript declaration files (specifically Leadtools.Documents.d.ts) included in the LEADTOOLS installation and looking for the lt.Documents.Service internal namespace.