Products

Home › Forums › eaDocX queries › Element Report for packages – no children?

Home › Forums › eaDocX queries › Element Report for packages – no children?

Viewing 7 posts - 1 through 7 (of 7 total)
  • Author
    Posts
  • 1 October 2014 at 3:40 pm #7770
    Ken Norcross
    Participant

    Hi All,

    I am trying to get to work an element report that targets stereotyped packages spread across our model.

    It seems as though the behavior of eaDocX is different when using the Element Report.

    If I directly connect a package to a section in the document everything works as expected, all of the children of the package are processed for formatting in the report.

    If I create an Element Report that targets the same package(s) the children of the package are not processed.

    This can be demonstrated in a single document with 2 sections, one section directly related to a package, and another section that finds the same package through an Element Report set up to use the package as a source.

    Both sections share the same profile definition, but the results are not the same. The Element Report section does not process the children of the package.

    My goal is to create an element report that will scan our complete model and report on packages with a certain stereotype (and report on the contained children and sub-packages of the package).

    2 October 2014 at 3:44 pm #7771
    Ken Norcross
    Participant

    Some additional detail…

    eaDocX v3.4.1.1

    Sparx v10.0.1008

    3 October 2014 at 10:26 am #7772
    eadocX Support
    Participant

    Is the problem still there in 3.5 ? I made some changes in this area, so it just might have got fixed…

    3 October 2014 at 1:10 pm #7773
    Ken Norcross
    Participant

    The timing is not good for me to upgrade eaDocX (nor Sparx) so I cannot answer this.

    9 October 2014 at 9:21 am #7774
    eadocX Support
    Participant

    Hi Ken – you’re quite – the behavior is different, and deliberately so.
    The Element Report collects all the elements of the required type into a flat list, then prints that list. So, if you tell it to collect ‘Package’ elements, you’ll get the packages all printed in a flat list, including sub-packages and sub-sub-packages, all the way to the bottom of the tree, but all printed in the same way. We deliberately don’t print children of packages, here, because you’d get lots of packages multiple times.

    If you want to print the packages ‘as normal’, that is, with their children and sub-packages, then they way I’ve done that is to connect the required packages to something else. In my case, this was an element which represented a particular software release, which I connected to packages of Requirements, Changes, Issue etc.
    This worked well, and allowed me to print documents for each release, even though the EA model wasn’t structured by release (it was by business area).

    9 October 2014 at 2:04 pm #7775
    Ken Norcross
    Participant

    Thanks, I have not thought of doing anything like this, this is an interesting technique and I will explore this, thanks!

    9 October 2014 at 8:07 pm #7776
    Ken Norcross
    Participant

    I will also explore model views and ad-hoc diagrams, thanks for the pointer to another direction.

  • Author
    Posts
Viewing 7 posts - 1 through 7 (of 7 total)
  • You must be logged in to reply to this topic.

Compare licence prices

Choose the licence that’s right for you and your team

Prices

Download a free trial

Download eaTeamWorks today for several free for life features, plus no obligation, 30-day trials of all the products: eaDocX, ea Revision Manager, eaSheets, Model Expert and PortfolioManager. Discover for yourself why we sell the world’s best-selling Enterprise Architect extension.

Download