runtime build of help system

[dpark]

Here is the scenario:

A few things to mention before laying out the scenario:


----
-the help system will not be deployed to the www.
-the application system (the thing we are building and shipping) will not be running on IIS.
-I am familar with the merging output at runtime - i've read the documentation and it seems to hinge on the previous two assumtions -- namely that the help system will be deployed to the www and that IIS is in the tech stack. Neither of the assumptions is true as stated above.
----

We have a plugin application system. Each plugin has a fragment of toc and for each toc entry there is a resource associatd with it. Nothing special here except that this is a plugin system.
Sure we will likely ship a set of plugins that — to the end user – appears to be a single application. But under the hood we know the truth. The application is a composition of all the plugins working together. The help system is the same. At the time we ship, the build time compilation of the help system is fine.

However, with the plugin system, it affords us (the company that shipped the software) to sell the client more pieces of functionality. This functionality would be delivered to the client through a set of plugins — as opposed to sending them another application that is built from ground zero – we can just extend the system with plugins.

Now – given that the new functionality will be delivered with plugins — and remember — each plugin contains it’s own help content — how can the plugin’s help system be ‘added’ to the help system that was compiled back when we shipped the base functionality? (before the new plugins were added). Will we have to ship a new help system too? That model simply doesn’t scale. That is why I am pursuing this ‘runtime’ build of the help system. Specifically, when the plugin application boots, it will look at all the plugins, gather all the help toc’s and files and then construct the help system.

Does this make sense? (think of the way the eclipse help system works - that is the model i am trying to convey)

I see that this is not supported (at least to my knowledge). So I am inspecting the output of Flare (in Webhelp format) and I see that it generates toc.js and toc.xml. Based on the looks of these files, I think I can write a js file that can generate these from the set of plugins at runtime. What do you think?

[HeraTech]

MadCap Flare has supported Eclipse Help since Flare 10 (which was released a couple months before your post). You don't say what version you're on, but is there some reason you're unable to use Eclipse Help, since that seems to be exactly what you're looking for?

[NorthEast]

Flare supports merging outputs at runtime - have you looked at this?
http://webhelp.madcapsoftware.com/flare11/Content/Output/HTML5_Output/AutoMerge/Merging_Output_at_Runtime_Using_HTML5.htm

You could build each module as a separate target/output, then put the output help for just those modules required in the AutoMerge folder.

[clturner22]

To revive this a bit...

Anybody had any luck not only creating Eclipse Help, but using Flare to (easily) author the text used in an Eclipse Cheat Sheet?