We're sorry GroupDocs doesn't work properply without JavaScript enabled.

Free Support Forum - groupdocs.com

GroupDocs.Total-Angular question

If we integrate GroupDocs.Total-Angular in our Angular app, do we then not require the server side component of GroupDocs? Is that in built into your angular example?

Thanks

@pkorwar

Please note that GroupDocs APIs are UI-agnostic. You can develop the front-end in any UI framework of your preference. This GroupDocs.Total-Angular application is just for the demonstration (how you can utilize UI with the back-end/server side API).
In short, you actually need the server side component.

So, should this Angular component use your server side using the API you provide? Can this back end be implemented using AWS lambda or does it need to be deployed separately on EC2 machines? Also, what programming language can this server component be ?

Also, what is the difference between GroupDocs api and Aspose API? Are you not the same company?

Thanks

@pkorwar

Aspose is our sister company.

Both have server side APIs. Could you please tell us your requirements? Are you interested in document conversion, document viewer etc?

Yes. Well, it could be any JavaScript framework at client side/front end.
As far as deployment or system requirements are concerned, please take a look at GroupDocs.Conversion’s system requirements.
Basically, all GroupDocs APIs work with these system requirements.

GroupDocs APIs work with both Java and .NET platforms. We also have cloud SDKs for different platforms. You may need to take a look at GroupDocs.Conversion (for instance).

We need to edit MS Word and MS Excel docs in an our Angular APP which is deployed in AWS environment. So, please tell us the details of how will achieve it.

Thanks

@pkorwar

What is your preferred development environment (e.g. Java, .NET)?

We would prefer java

1 Like

@pkorwar

Please take a look at GroupDocs.Editor for Java. It’s a back-end API that could be implemented in any Java application. Explore the minimum system requirements.
How API works?
The main feature of the API is to edit most popular document formats using front-end WYSIWYG editors without any additional applications. You can just load document via GroupDocs.Editor into any WYSIWYG editor, edit document in a way you want and save it back to original document format.
Please clone and explore this open-source Java application.

So, if my understanding is correct, we will need an editor like CKEditor or TinyMCE to be embedded in our app. Then this client side app calls some REST end points to edit paragraphs/excel cells/tables etc related to MS docs. The REST end points implement POST/PUT using the API you have provided. Is this how you do? If so, when the client editor make some text as bold or italics, can that meta-data be passed to your API and are your APIs designed to handle meta-data that MS docs need?

Also, the server side implementation which uses your APIs - can they be implemented as AWS lambda or it is not possible?

We are investigating this scenario. Your investigation ticket ID is EDITORJAVA-613.

Hi Pramod,

From what I can see, you need to edit MS Word and MS Excel documents using Angular application, which is deployed in the AWS environment, and you prefer the Java dev platform.

For such requirements we can suggest a GroupDocs.Editor, it is a part of a GroupDocs.Total. GroupDocs.Editor is delivered in three forms:

  1. Standalone library for .NET platform - a GroupDocs.Editor for .NET

  2. Standalone library for Java platform - a GroupDocs.Editor for Java

  3. And a cloud SDK for .NET and Java, which, in fact, are the wrappers, that communicate with our server through the REST API.

All of them have only a programming interface, they have no GUI, even a command prompt. This is done in order to make the product compatible with any interface — it can be anything, even a WinForms. But, of course, GroupDocs.Editor is oriented on web-development. In order to enable a possibility to do something with the document in the browser, without using installed MS Office, browser plugins, and so on — you need to deliver it to the browser as HTML/CSS. So the logic is the next.

You specify a document (DOCX, XLSX, or even a PDF for GroupDocs.Editor for .NET) for the GroupDocs.Editor, specify and adjust the options, and GroupDocs.Editor converts it to the special editable HTML/CSS. Then you push this markup to the client-side to your WYSIWYG-editor, which can be any client-side editor, which is working in the browser: TinyMCE, CKeditor, Summernote, or you may develop such an editor on yourself. End-user edits the document content in the browser. Then this content is pushed back to the server-side and passed to the GroupDocs.Editor. GroupDocs.Editor, in turn, performs another conversion - from HTML/CSS to the desired document format at this time. And you got the edited document. For example, we can imagine the whole pipeline as the next:

original DOCX -> original HTML/CSS -> ...user edits... -> edited HTML/CSS -> edited DOCX

From this description you may see that your assumptions, described in your last message, are not correct. GroupDocs.Editor doesn’t require so tight client-server interaction, like every edit on the WYSIWYG-editor fires a request to the server, where every edit (like make text bold, or add a word, or press a line break) is accounted and processed like in a open editing state. Such complex and intensive communication makes the development of a WYSIWYG-editor too heavy.

GroupDocs.Editor is actually stateless. Original HTML/CSS is loaded to the WYSIWYG-editor in the browser. Then the user makes any edits he wants, without intermediate requests to the server. When editing is done, edited markup is collected, pushed to the server-side, and passed to the GroupDocs.Editor, from which it generates output DOCX/XLSX/PPTX/PDF/anything-else.

Now what regarding Angular - please visit this page: https://products.groupdocs.app/editor/total

This is our demonstration - we developed this web application in order to show capabilities of the GroupDocs.Editor. Play with it: upload any document, try to edit its content, then press File->Save button and then download the edited document in desired format. Evaluate its possibilities in representing complex documents and distinction between original and edited document versions.

This web solution uses a GroupDocs.Editor for .NET, that is running on server-side. On the client-side, in turn, the WYSIWYG-editor, that you see, was developed by our team using Angular web framework. It doesn’t use any third-party components, except the Angular itself. But this is not required - in theory, it can be developed using any other framework, or even using a pure JavaScript.

Concluding, from what I can see, I suggest you try a GroupDocs.Editor for Java and some WYSIWYG-editor, maybe based on Angular too, like we did. Regarding your last question about AWS lambda — unfortunately, it’s hard to say, because we do not use AWS lambda in our infrastructure and have not faced it earlier. I strongly recommend you to try a trial-version of the GroupDocs.Editor for Java — it is absolutely free, has no time limitation, and has full API, features, capabilities, like the licensed one. The only distinction - it shows the watermarks atop on the pages and truncates document pages/tabs/slides to only first and second.

Thanks for your interest in GroupDocs and sorry for such delay.

If you have any questions, feel free to ask them any time.

With best regards,
Denis Gvardionov
GroupDocs.Editor Project Lead

Thanks a lot Denis for the detailed explanation