RTF Editor and page headers and footers

[skiwi]

I have been struggling to determine where the page header and footer comes from.
That is

• does it come from the Documentation package RTFTemplate
• does it come from the first model document RTFTemplate
• does it come from the current model document RTFTemplate?
• does it come from the previous or current document artefact?

It seems that the page header and footer come from the Documentation package RTFTemplate.

If Documentation package RTFTemplate does not have a header or footer it seems that the header and footer comes from the first model document RTFTemplate that does have a header and footer (ignoring any document artefacts that are previously part of the document that have a header and footer.

My issue: this is neither clear or expected. Why are not document artefacts equivalent to model documents for participating in, and generating documents.
Neither does it seem documented clearly what the behaviour is or should be.

My request: document clearly the expected behaviour of header and footers.

Make all document parts equal.

[skiwi]

NB: it appears that even if the documentation package RTFTemplate has no page header or footer, AND NO model document RTFTemplate has a header or footer, the document artefact header and footer are ignored !

[Graham_Moir]

I agree it's not clear in the help.  However I have it confirmed from Sparx that the following is true for Headers/Footers :

1) If the Master Document (container for the model documents) has a template defined via the RTFTemplate tagged value and that template has headers/footers then these headers and footers will take precedence and override any defined in the model documents themselves.  This allows you to have consistent headers/footers throughout the virtual document and consistent page numbering.  I have got this to work.

2)  If the Master Document RTFTemplate tagged value is blank, then all subdoucments render their respective header/footer.

regards
G.

[RoyC]

Firstly, a Document Artifact is for creating Linked Documents, not for creating parts of Virtual Documents. In case the reference to them on the Virtual Documents Help topic is misleading, I have added the comment " - used for Linked Documents -" to that reference. The linked document is created in isolation from a report, is peculiar to the element it is attached to, and has no impact on the report template.

They are not the same as Model Documents. It's a subtle distinction, but on a diagram the Model Document has a line under the element name, whilst a Document Artifact does not.

Secondly, I have added a tip to the Virtual Document topic to explain (and generalize) the point that Sparx Support made to Graham. It will be there in the program Help for the next release of EA.

[Graham_Moir]

Roy - your comments are very interesting.   While I'm sure your distinction between model documents and document artifacts/linked documents is accurate, we definitely blur it because we ARE using document artifacts/linked documents as part of our virtual documents - even if it is indirectly !

As a result I cannot wholly agree with your statement "the linked document is created in isolation from a report, is peculiar to the element it is attached to, and has no impact on the report template."

Let's take the example of "Project Background".  This is a document section that can appear in many different documents but has no need to pull in various parts (elements/diagrams etc..) of the model.   We want to write this section once and pull it in to each document that needs it.   So we create a document artifact with a linked document, name it appropriately and write it using the standard heading styles etc.. from normal.rtf.   It's then ready to be used.

Now all we need to do is pull it in to each virtual document.

We have a documentation view which contains a folder called "Generic Sections".  Within that we have a subfolder called "Generic Project Background" and within this folder there is only one element - the document artifact for our Project Background that we've just written.

Now I can create a master document/virtual document and pull in the project background.   I do this by creating a model document within the master document just for the project background, naming it appropriately and then dragging the "Generic Project Background" folder mentioned before, onto the model document to include the generic section.   The final piece of the jigsaw is that we have an RTF template that does nothing except pull in linked documents - this RTF template is assigned to the model document we've just created and as they say Bob's your uncle.

The document artifact/linked document is pulled in to the overall document at generation time and receives the master header/footers and section/heading numbering.   The table of contents is correct, and if we need to we can also move the section up and down the virtual document at will using the standard project browser functionality.

It took a long time to work all this out - if there's a better way of doing it, I'd certainly like to know, otherwise is this something that should go into the help as well ?

regards
G.

[RoyC]

Everything you say is correct. But what you are doing is using a template to format the documentation of elements with the proviso that IF the element has a linked document the content of that document is inserted <here>. It just happens that you have made absolutely sure that those elements DO have linked documents. The content of the linked document (created independently of the model document, master document or templates) is formatted by the template, not the other way around.

[Graham_Moir]

I agree Roy,  I just felt that your original message implied that document artifacts couldn't be used in virtual documents when in fact they can, even if it is in a longwinded way and with a template determining their format. In short with a bit of jiggery pokery a document artifact/linked document can :

- be included in a virtual document at any position desired
- can be formatted/styled in line with all other (model) documents in the virtual document - including headers/footers
- be properly shown in the table of contents

I'm still interested in knowing if there's a better way of doing this for the type of "generic" section I've described - we have quite a few of these.