Web Published output as an exe

[Mritunjay_g]

Hi All,

I have a web based published output containing html files, js files and some folders. Content folder is containing all topics(*.htm). I have to commit output on svn where anyone can see or make changes in code. Can we have output as an object code.... in the exe format?

Or any other security measures ? Please suggest......your help will be appreciable.


Thanks,
Mj

[AlexFox]

Perhaps a CHM output would be more suitable?

[RamonS]

What is the concern of folks making changes? That is the point of a shared source repository. You should also keep the sources in source control and not the compiled output. As far as your problem is concerned, Flare as a means to zip a project. You could submit the zip archive rather than the source files, makes it a bit more difficult to change content. You can do the same with the binaries (compiled output), but I wonder what the point would be. One reason why folks submit compiled output to source control is for build processes to consume content from one place. Flare can be included in the build process through command line builds, but this comes at a cost (reduced price build license) that many circumvent by breaking with the source control paradigm. Happens anyway as soon as 3rd party components are used in the application.
We might give some better advice if you can explain more what the original issue is.

[Mritunjay_g]

Thanks RamonS and AlexFox,

My senior asked me to make project output as object code, no one must able to see the contents of project. Otherwise someone may change the contents or style.

I put output in svn from there technical team takes and pass it with customer build. Anyone who can access the "deploy" folder can access the project content.

I am publishing project as "File system" in destination. Anything need to be done at publishing part?

I may not put clear words as I am not technical guy, pls suggest.

Thanks in advance,
Mj

[RamonS]

You can package the output any way you want, but in the end it either needs to be shipped to the customer as WebHelp or deployed to production servers as WebHelp. Otherwise customers will not be able to consume the content. Packing it as zip archive or any other format will essentially only keep your own coworkers from mucking with it. If that is a concern you have far bigger issues at hand.

[Mritunjay_g]

Thanks RamonS,

Yes, I believe they want complete security.....bigger issue at hand.
I have not checked with ZIPing the project, will it work properly ?

Again thanks RamonS.


Mj

[Mritunjay_g]

Hi RamonS,

Actually scene is like this,
1. I will put project in svn.
2. Technical team will pass it with the customer build from svn only.
3. Customer will press F1, on clicking the F1 the respective page(of my project) will appear.

Will everything work after ziping the project ?


Thank you for guiding me,
Mj

[RamonS]

Actually scene is like this,
1. I will put project in svn.
2. Technical team will pass it with the customer build from svn only.
3. Customer will press F1, on clicking the F1 the respective page(of my project) will appear.

Will everything work after ziping the project ?

Out of the box with no further changes: No. What can work is when the application unzips the archive and places the WebHelp files to a location from where they can be served up to the users. The apps needs to check if the expanded content is already in place and then skip the extraction step to avoid a lengthy response time when help is accessed. While that is doable it will only reduce the size of the deployment package or installer, although most include compression anyway.

I'm still unclear who you want to keep from editing the files. End-users or your own coworkers?

[Mritunjay_g]

Thanks RamonS,

I'm still unclear who you want to keep from editing the files. End-users or your own coworkers?

Actually both, we are into healthcare solution management so somewhere we have our implementation team onsite and some place customer has to take care of Impl part... we just give them the latest build.

To make the uniformity(style and contents) across the customers, there must be single window for documentation modification.

There are two authorized persons(creator,myself and technical person who makes build) in picture before documentation go to the customer place. Just to avoid changes through third person(non-authorized) we are doing this exercise.

Hope now my words are clear.

Really, very thank you for putting your efforts to resolve my query.

Mj

[RamonS]

Thanks for clearing things up. In that case, you may want to look at an entirely different approach. You essentially want to retain control over the content because it is important that the content follows specific rules. Dropping some HTML files on some server you have no control over opens the door to easily edit the content of the files potentially without leaving a trace.
Here is what I'd do: host the help on your own tightly controlled web server. That server only needs to be as beefy as it needs to serve the requests coming in. The application will need to change to serve up content exclusively from that source. The downside: the app needs to be able to access the Internet.
If that is not an option you may want to evaluate 3rd party tools. I ran a quick search online and came across DecSoft's HTML compiler (https://www.davidesperalta.com/htmlcompiler). Based on the description it does what you want. They have a trial offer, but if you want to use that option it will cost you 140€ for a license. My guess is that tool contains a browser control that displays the HTML pages held in memory. There is nothing stopping you from rolling your own, seems like a nice project for a summer intern in development.

[Mritunjay_g]

Thanks RamonS,


Thanks for your valuable input. I will talk to senior management, lets see what they say.


Thanks
Mj

[Mritunjay_g]

Hi RamonS,

Gone through site, they are dealing with windows system. I am dealing with java application, jboss server.



Well, thanks a lot.
Mj

[RamonS]

My suggestion then is to roll your own. What you need is an executable that contains a fairly recent browser engine and a means to display HTML files, execute JavaScript, and process parameters passed to it so that you can make context sensitive help calls. That is a development task for which I suggest to seek help in other forums. I could not find a solution that compiles HTML/JS into a jar file.
Using a web server that gets accessed is the other option and likely the easiest to implement if the client systems have Internet access. You may also look into using the JBoss server as a proxy, that way only the server needs Internet access while the clients receive the help content from the server.
You may also consider creating a PDF and put a password on it. It will not be context sensitive help, but that may be the compromise to make in order to deliver the help with the tools you got. That said, there are plenty of tools out there that can unlock a PDF with ease. The password would only make it a bit more inconvenient to muck around in the content.
The only other idea I have is to revamp how help is delivered. Add a help button to each dialog and page or intercept the F1 key press (or any other key or combination). Clicking that button or pressing the key will open up a help window or a panel within the application window that contains the help content. That may or may not be in HTML and not use JS. You need to figure out what format is supported, one avenue (although a rather lame one) is to use Flare to craft a Word document and the export that document to a flat text file. Maybe there is a module for Java that can process markdown or Wikimedia format. That way you get at least some styling options that you can control.

Good luck!

[Mritunjay_g]

Thanks RamonS,

Yes, we are using F1 key facility, on clicking, the respective menu help pops-up.
We need only HTML5 help not pdf.

Well, Thanks Ramon for your continuous efforts.

Thanks,
Mj