I'm being realistic friends.
What I have demonstrated here is just the top of the iceberg. For those who have worked with document generation, custom reports, implement such solutions in the built-in editor, makes the work quite costly or impossible for the following reasons:
1) Too much overhead for creating simple solutions: No grouping of elements, sort records from a list/collection, sub-reports loop, conditional statements, hide fields/labels, labels and fragments with specific rules, support for styles and conditional styles, etc. .; You must write source-code for some cases.
2) Lack of functionality to create custom graphics. For example: Pie, Bar, Line, Scatter and multiple-series charts.
3) Lack of functionality for creating design elements. For example, lines, arrows, boxes/frames, and rectangles (elements present in simple reports).
2) The tool provides a tied way to build custom reports: You will be required to create an absurd amount of fragments or create a virtual document (which is also a complex solution);
3) The use of JScript, JavaScript and VBScript makes the development of these reports to KEEP and EVOLVE with too much effort. Especially because you will have problems to run them because not every machine supports scripting execution and ActiveX by default - trust me;
4) The runtime generation can also be a problem if you have the need to generate a lot of documents: you will have to wait 1 minute for each document to be generated by the amount of logic processing algorithms implemented.
5) Documentation and tutorials: The material is too poor. You can search on google someone who has performed complex reports in EA: you will not find!
Geert in analysis of your responses:
"both requirements quoted are more of a" solution "then They are" requirements ""
> This is a feature that both the Jasper Reports and Crystal Reports use (widely known tools) so I do not see as a solution but as a characteristic of a report generator tool: it is a common need.
"Sometimes you can solve it by creating different templates (one with and one without the specific field or table)"
YES! In my solution I needed to create about 20 fragments to generate only one section! This is ridiculous! In other tools I can do the same thing using only 2 report fragments.
Assuming you need a sub-report that has 10 fields: If each field has to be hidden by a specific rule, you will have to create 10 sub reports. But if other rules than these apply, you will have N x 9 x 8 x 7 x 6 ... templates for creation.
In other tools I create just one template and apply the necessary rule in each field, reducing my efforts and the amount of used templates: reuse.
"Sometimes you have to convince the client that his requirement is rubbish and not worth implementing"
Does not apply to my scenario: All the models used are in accordance with the RUP templates proposed by a common software factory. I do not even entered the scope of customer needs, as this is an entirely different and an even greater demand scenario.
Folks, this is why I came to the conclusion described above. Why reinvent the wheel if the market already has more robust solutions to meet the conditions above? Why delegate this work to a professional to make it to the point of writing specific solutions and maintain a huge load of nearly identical templates to meet basic requirements.
The RFT generator works basically like a text-extractor not a reporting tool.
I really like the EA for everything else, but failed to convince me after six months of use to work with document generation.