Streaming content using .NET viewer 3.0

GroupDocs.Viewer Product Family
1

Hi Team,


In the previous versions of the viewer I was able to set content rendered by the viewer using a URL, however it look like in the 3.0 implementation this is not possible. Do you guys have any available workarounds for this issue ?

Additionally, I heavily leveraged the widget methods for searching, zooming, and paginating. Is this functionality also available in the new 3.0 .NET Viewer ?

I have downloaded the new GroupDocs.Viewer.NewFrontEnd from github and have it running in VisualStudio.
2

Hi John,


Thank you for your inquiry,

Here is the inline response of your points.

In the previous versions of the viewer I was able to set content rendered by the viewer using a URL, however it look like in the 3.0 implementation this is not possible. Do you guys have any available workarounds for this issue ?

[GroupDocs] A document can be rendered by passing its URL like the following code snippet.
//Get Configurations
ViewerConfig config = Utilities.GetConfigurations();

// Create html handler
ViewerHtmlHandler htmlHandler = new ViewerHtmlHandler(config);

//Instantiate the HtmlOptions object
HtmlOptions options = new HtmlOptions();

if (!String.IsNullOrEmpty(DocumentPassword))
options.Password = DocumentPassword;
//Get document pages in html form
List pages = htmlHandler.GetPages(new Uri("http://www.example.com/sample.doc"),options);

Additionally, I heavily leveraged the widget methods for searching, zooming, and paginating. Is this functionality also available in the new 3.0 .NET Viewer ?

[GroupDocs] Please note that the new GroupDocs.Viewer is a UI-less API exposing only UI-less+back end document rendering APIs in which object oriented approach has been implemented in a very simplified way. The functionalities which you have mentioned above are relevant to the Front End. But the new GroupDocs.Viewer API allows users to make their own front end. No need to be dependent on API. User can mold the Viewer output results according to their front end needs.

Thanks for your understanding and cooperation.

Warm Regards



3

Ok, thankyou. The stream worked great.


On another note, is the way the Viewer 3.0 module is constructed going to be how all the other modules are written when their version 3 is released ? (ex. only a back-end and no UI controls)

I guess what I am trying to figure out is if there is going to be consistency in how the integrated modules are invoked ?

Thanks,
John
4

Hello John,


Thank you for the acknowledgement and your query.

Actually I couldn’t get your perspective about the modules.
I would like to request you to elaborate more about what you wanted to say.


Thanks in advance.
5

For example in the viewer 2.18 module a script could be returned from the .NET application and rendered in the web page. This encompassed all the stuff needed to use the viewer.


Then with viewer 3.0 the request returns pages which encompass their own html and no embedded scripts are needed. However, all the front end UI controls were removed.

What I am trying to find out is the direction all the other modules are headed ?
- Are the request going to return script blocks that encompass all the necessary functionality ?
- Are they going to be like the new viewer which disintegrates the front end from the back end?
- Ultimately I am looking for an answer as to how all the other modules are being written and if there will be any consistency in how a programmer interacts with any groupdocs module?


My use case is I am hosting these modules in IIS and making calls from a front end web application to render the groupdocs module in the browser. This has been relatively straight forward with the Viewer module, but it doesn’t seem that is the case for the signature module or the annotation module.
6

Hello John,


Thanks for your explanation,

Below is the inline response of your questions.


What I am trying to find out is the direction all the other modules are headed ?
- Are the request going to return script blocks that encompass all the necessary functionality ?
[GroupDocs] Yes surely, all modules (starting from 3.x) are providing essential functionality in a generic way.

- Are they going to be like the new viewer which disintegrates the front end from the back end?
[GroupDocs] Yes exactly, all modules (starting from 3.x) are disintegrating the front end from the back end.
- Ultimately I am looking for an answer as to how all the other modules are being written and if there will be any consistency in how a programmer interacts with any groupdocs module?
[GroupDocs] Yes every module has been written in a same way which is that to provide out put in simple and generic form. So that the programmers can use that output easily for other modules. Like Viewer 3.0.0 provides generic list of HtmlPage object as output. and HtmlPage has a property which return html content in string form. Same case is with ImagePage which returns a general stream of rendered image.

Thanks for your understanding and cooperation

Warm Regards