This project is read-only.

Make EcmaDoc output format more dynamic

Jan 12, 2011 at 11:40 AM


I've recently been looking into generating "DITA" documentation from JScript and naturally ended up looking at EcmaDoc. EcmaDoc does its transform job by using XSLT's which lends itself very well to be used as transform to other formats. The project file however has to be defined with a 'file extension' (html by default). This limits the capabilities of the EcmaDoc tool.

I would like to suggest to make changes to the EcmaDoc tool so that an output format becomes 'a plugin'. Where the current HTML output type is delivered with the project out of the box. Other plug ins can then be used to generate other types of output (like .CHM or .Dita).


Jan 13, 2011 at 1:34 PM
Edited Jan 13, 2011 at 1:34 PM

Sounds like a great idea. I've been meaning to look into generating CHM format at some point in the future, when the HTML version is stable and feature-complete enough. One thing still on my plate is to provide document-level API documentation in the output, as the current version does not produce any document-specific information in the output. Internally this has already been done, what remains is to generate and link to document-specific files.

With your suggestion in mind, I will explore how output-plugin architecture can best be implemented within EcmaDoc. On the same note, if you have thought about it, looked at the code and feel inspired, you are more than welcome to contribute to EcmaDoc by writing this yourself. I will add you to project developers if you request it.

Jan 14, 2011 at 6:03 PM

I thank you for the offer of becoming a team member and i am interrested.

My thoughts have been moving into the direction of:

- Make the parsing component an plug in model
  This will allow us to parse other languages than JavaScript (Java and C# being the first two that would be my priority, but if its interface based, we can have anyone write a new 'parser plugin' for any type of language).

- Make the output component a plug in model
   This will allow us to output to many different formats, where the current "HTML one" is 'present'. A "DITA" output component would be on my priority list.

These idea's might require the current 'intermediate' format to be extended, but i see no real big issue with that. The other things that need to change would be that the output generation is less coupled then a "input structure one-on-one with output structure"; this is a little bit more tricky if we want to get this 'right' in interfacing.

My thoughts.

Jan 17, 2011 at 6:52 AM

I have added you to the team as a developer. Feel free to start implementing changes you propose, as using a plug-in model both for parsing and for output sounds like a good idea. Once you lay out the foundation for these architectural changes, I will be able to pick it up and contribute on it from my end.