Well, virtual documents are not without their problems either. With virtual documents you end up with models which need to be maintained, whereas a scripted document generator pulls everything together on the fly and outputs the document.
As to virtual documents affording greater flexibility, that is a matter of opinion. A script is no less flexible than a model, it's just a question of which way of working you're more comfortable with: code or models. I should also point out that with the semi-automated approach you end up having to maintain both a script and the resultant set of models.
I would sum up the different approaches to document generation as follows.
With the most basic, just-hit-F8 way of generating a document, the document structure is tightly linked to the project browser structure. If this is something you can live with, then that's the simplest way to go.
With a virtual document, you put together the document structure manually in the form of a model. The document structure survives restructuring of the source model (up to a point), although of course if you delete parts of the source model your virtual document breaks. (Silently.)
With a scripted document generator, the structure goes in the script. This allows you to lay out your document according to other structures than the browser hierarchy -- you can easily follow connectors, instance/classifier relationships, attribute types, RefGUID tagged values, etc, and base the document structure on that. You can also InsertText(), which allows you to put in results of calculations or anything else that takes your fancy.
The combined script-and-virtual-document method creates a virtual document based on a source model and a structure hard-coded in a script. This gives you the option of modifying the virtual document structure after it's been set up, but it also brings the drawback that virtual documents have: the virtual document is based on the state of the source model at some point in time but has no in-EA relationship to it, and so needs to be maintained in lockstep with the source model.
When I refer to scripts above, the same applies to Add-Ins. But in terms of document generation, there's nothing an Add-In can do that a script can't (except automatically trigger a document generation based on some event fired by EA). Add-Ins are compiled, of course, so the development turnaround is longer.
In general, for complex documents I prefer a scripted approach in many-of-the-same scenarios, where many documents of the same type (eg software component requirements specifications) are to be produced from many distinct, but identically structured, models. In situations where the documents are fewer in number but perhaps broader in scope, such as a progress report on the requirements analysis work taking place in an EA project, I favour virtual documents. I have yet to find a use for the combined approach.
In this situation, where you want the process to generate a document and do a bunch of other stuff at that same time, I would advise against virtual documents in any guise. Virtual documents "freeze" a document structure at some moment in time, which is useful if you want to make changes to the document structure in between creating the virtual document and generating the output document but not otherwise. If you want the generated document to reflect what's in the source model at the moment of TFS synch, and if you don't want to generate the document at any other time, I see no reason to set up a virtual document.
/Uffe
