CODEWITHSUNDEEP
javascriptc#jquery
CriketerOnSO
CriketerOnSO

Reputation: 2620

Opening an instance of Microsoft Word from Javascript

I am building an application that will allow user to open a word document through a web page. This web application will open the word document using the local word instance on the machine.

I have two working solutions.

  1. Using ActiveX (Only on IE)
  2. Since the application is intranet application, I am using PsTools in the web service to remotely open word instance on remote machines.

The second architecture is what I am following right now. It is based on a Web Service which receives machines name through Javascript/jquery call. Later in the web method I am using PsTools to remotely execute MS Word instance on remote machine.

Both the architecture works, but both of them have limitations. With ActiveX I can use it on IE and it also requires changes in network policy to allow ActiveX. With PsTools, it is working great but I can't get the path of Word.Exe and I can only assume that it would always be at \\machinename\C$\Program Files(x86)\.....

We might make this application public as well and in that case our solution with PsTools will not work anymore.

I was just wondering if there is any other more suitable/cross browser way to open local word instance through web application ?

The document has to be modified on a remote location, one option would be to let the user download the document, then modify it and upload it to the server, this is out of question since we are replacing a thick client and wants to keep the user experience same

Upvotes: 3

Views: 6470

Answers (2)

Abhitalks
Abhitalks

Reputation: 28387

I am building an application that will allow user to open a word document through a web page.

If it is an Intranet scenario, then you could use application protocol with Office URI schemes for links to the documents which will then open in the locally installed client.

The Office URI schema is like this:

<scheme-name>:<command-name>"|"<command-argument-descriptor> "|"<command-argument>

For Word specifically, an example would be:

<a href='ms-word:ofe|u|https://example.com/example.docx'>Edit</a>

Where, ms-word: is the scheme, ofe command stands for open-for-edit, the u is the command-descriptor to use the URI that follows, and finally the URI to the document itself. There are other commands like ofv (open-for-view), and nft (new-from-template), and also other command-descriptors like s for save.

Here is the complete reference: https://msdn.microsoft.com/en-us/library/office/dn906146.aspx

The protocols are registered with Windows when the Office client is installed.

You could enable WebDAV easily on your IIS server. The WebDAV client is built-in with Windows at the client-side.

You can also use components like FFWinPlugin Plug-in which is part of the SharePoint Foundation, or OpenDocuments Control which is an ActiveX control installed along with the Office client.

We might make this application public as well

I would discourage you from doing that, unless your company owns or deals-with services like OneDrive or Office.com. This can quickly get tricky as mentioned in the other answer. Moreover, enforcing a proprietary client on general public is not a good idea anyway. Further, even Microsoft's own solutions do not work reliably across browsers and work best with IE only (even Edge has problems with this), which would be forcing a specific browser to general public. Not a good idea.

However, if you really need to, then it would be better if you could use some of the solutions already built around WebDAV. Alfresco ECM (enterprise content management) is one example of public offering which uses WebDAV similar to your use-case.

There is another one by IT Hit and a live demo is here: http://www.ajaxbrowser.com. They also have a basic tutorial on how to setup your own WebDAV server on the same lines as your use-case. You will need to find their documentation.

Upvotes: 8

Cahit
Cahit

Reputation: 2534

When you say: "We might make this application public as well", what kind of scale are you talking about? Just a couple of folks from the a team, or as a real web application that needs to deal with edit conflicts, transactions, locking, performance, etc.? Even the intranet solution you mentioned will likely become a headache as soon as 2-3 people start to edit the same document.

For this type of document sharing, you basically have two options:

  1. Significant investment in a rich web UI that behaves similarly to MS Word, with back-end services that will store the info in a scalable data store and provide simultaneous edits and document downloads, or
  2. Integrating with a third party vendor API or white-label provider that offers similar capabilities for a fee. E.g. Box.com APIs, HyperOffice, FirePad, etc.

This would be a super-simple problem to solve if you can convert the document in question to a type of form. There are probably a hundred different services that offer embedded forms functionality with excellent reporting and database management. If a document in Word format is needed, then your app would just convert the stored data to a .doc/.docx document for users to download at will.

Whatever direction you go with, try to get out of the PsTools-based current setup. It's like a rinkydink house of cards and as @Matt-Burland mentions, likely to cause a security disaster pretty soon.

Upvotes: 1

Related Questions