Cloning package trees and their eaDocX docs

[Phillip Khaiat]

Hello,

My team and I will be using the same structure over several projects. Within EA today, when we copy over a document the links between the model documents and the packages stay intact (i.e. the new model documents point to the right package in the new project). Right now we have to manually update the sections in the EADocX document to point to the correct packages. As we have several projects that we will have to do this for we were hoping that in a future release the cloning process could become automated in eaDocX.

Meanwhile, a stop-gap measure might be to create a macro to update the GUIDs in the eaDocX document sections. Any suggestions?

Thank you in advance for your help.

Cheers,
Phillip

[eadocX Support]

I’m not sure I fully understand the Use Case…but here goes:
I have an eaDocX document, which documents some Packages (#1, #2, #3).
I want to create a second document, a ‘clone’ of the first, but which documents Packages #4,#5 and #6.
So I need to tell the second document about the list of packages it needs to document.
What about any Element Reports, Matrix Reports etc which the document contains?
Also, is the idea of Model View-based document, in 3.4, any use to you ?

[Phillip Khaiat]

You have the right idea. Think of the package tree as an EA Base Project. Its structure will be used as a staring point for new projects, all of which are required to produce the same set of documents from the same package tree structure. Using the RTF generator, I would include all of the virtual documents in the Base Project package tree. When the Base Project is imported, stripping GUIDs, the new RTF model documents will have all of their links updated to point to the new packages, giving me a cloned project with a cloned set of reports (we have 12 documents right now). I want to be able to create a new set of eaDocX documents that pull their content from a newly cloned base project in the same way. That would include the Element and Matrix Reports.
I like the new reporting from model views feature, but can’t see how I could use it to do this very easily without creating a new set of views for each cloned project package. Some of our documents refer to about 20 packages, so I would hate to break the direct link between package content and document, which is one of the attractive features of eaDocX.
To use your example, what I want is:

1. start with a document which refers to Packages (#1, #2, #3)
2. export those packages, & import them stripping GUIDs to get Packages #4,#5 and #6
3. easily clone the original document to get a new one referring to Packages #4,#5 and #6

[eadocX Support]

Ah – I think I’m starting to understand…
So, at the point after you have imported the new packages, and created some new GUIDs, I can’t quite see how we can specify which ‘stuff’ the document should use.
The Document has a arbitrary number of sections, which might be a ‘simple’ section, printing a Package, or Element, or Diagram (or Model view now), or be Element Reports (also keyed on a Package GUID, or EA Search, or be a Cross-ref report) or a Matrix (also has 2 x Package keys). Or a Project-type section e.g. Glossary, which probably should stay the same as the parent document.
All of these would have to be set at the point where the document is cloned.
Can this be done automatically with RTF? How does it know where everything is? Is it done based on relative position of the package/element/diagram in the package tree ?

[Phillip Khaiat]

RTF does it by treating the «package» attributes of model documents as links within the model, and updating their GUIDs as part of the connector clean-up process during import. (Sparx used to treat the package names as links, which did not work very well). I can think of a couple of ways in which eaDocX could piggy-back on this process: make the «eaDocXDocument» element an extension of the RTF model document, and add all of the links to packages currently stored as GUIDs in the XML as «package» attributes to them. If that element is imported as part of a package tree using the Strip GUIDs option, Sparx will update all of the GUIDs, giving you an element containing a set of named packages with updated GUIDs, and allowing you to build an “update links” function for an eaDocX document. You could also do the same kind of thing by using connectors between an «eaDocXDocument» element and the packages included in the document, although I think that this would be a less elegant solution.
I understand that this is not a simple feature to build, which is why I would be happy to settle for a simple macro allowing me to manually replace one set of GUIDs with another in the document XML for now.

[Author]

Posts