nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

M2Doc: Filter and display diagrams from package

medini_1061189784

I have a container package which contains multiple diagrams

What I would like to do is filter for the diagrams relative to the topic of the report e.g. HMI.

How do I access the diagrams with the checklist set up as so?

I would have thought it would be using the "the_owned_elements" property, but that only shows the parts.

Reading the user guide it mentions that the diagrams are accessed via proxies. But I'm confused how to use that within the report template.

Thanks!

Reece

Find more posts tagged with

medini

medini legacy

Accepted answers

medini_1024169437

Well, that's indeed bit tricky - though not impossible. I did not make it quickly but I made some progress I want to write down here so others may jump in or you may continue. Main idea: here are some nice utilities in existing script libraries like diagram.js for example "getAllDiagrams(scope)". We could use the eval() service to evaluate a sophisticated java script but that would mean, lots of JS script in our m2doc and we don't want that.

My idea: wrap the function by a slim M2doc scripted service! See the other article on scripted services to understand the idea. What I did:

I copied the default diagram.js to "config/scripts" (normal location, maybe .lib if you lke)
I wrote a small services.js and put it to confi/reports
The service looks like this - it wraps the real fucntion:

load("diagram.js");

(
	{
		getAllDiagrams : function(scope) {
			var dia = getAllDiagrams(scope);
			return java.util.Arrays.asList(dia);
		}
	}
)

As you see I had to wrap it and return the result as list because m2doc cant handle arrays. Last was to write the m2doc:

So that at least gives me all diagram names when I bind a sysml model to scope, you may try.

The drawback: getAllDiagrams does not work for packages yet, someone has to fix that. But you may extend it in services.js and filter them there.

Happy Reporting

Jan

All comments

medini_1024169437

My idea: wrap the function by a slim M2doc scripted service! See the other article on scripted services to understand the idea. What I did:

I copied the default diagram.js to "config/scripts" (normal location, maybe .lib if you lke)
I wrote a small services.js and put it to confi/reports
The service looks like this - it wraps the real fucntion:

load("diagram.js");

(
	{
		getAllDiagrams : function(scope) {
			var dia = getAllDiagrams(scope);
			return java.util.Arrays.asList(dia);
		}
	}
)

As you see I had to wrap it and return the result as list because m2doc cant handle arrays. Last was to write the m2doc:

So that at least gives me all diagram names when I bind a sysml model to scope, you may try.

The drawback: getAllDiagrams does not work for packages yet, someone has to fix that. But you may extend it in services.js and filter them there.

Happy Reporting

Jan

medini_1059007410

Hi Reece,

If the diagrams are all on one level within the SysML container package, then this is also possible without JS Services.

Based on the access to all diagrams of a model ({ m:for diagram | ftaModel.mediniGetOpposites('originalModel').eAllContents(projectmodel::PJDiagram)->sortedBy(d | d.name) } as in the VTOL example report) you can apply a filtering for the container package.

{ m:for dia | mySysMLModel.mediniGetOpposites('originalModel').eAllContents(projectmodel::PJDiagram)->select(dia | dia.canvasElement = myPackage) }

...

{ m:endfor dia }

You need two variables:

The only challenge is that we need the SysML model (which "owns" all diagrams) and I don't know of a recursive function to get to the model from anywhere within the SysML model. AQL has a nice feature to find the next container of a certain type, but the root element within the model is the same type (SysMLContainerPackage) as all other packages. That's why you need the second variable. Maybe that's ok for your use case. Alternative would be multiple ".eContainerOrSelf(sysml::SysMLContainerPackage)" in a row (as many as you have maximum levels in your model), then you would only need your package.

If your diagrams are not directly below the package, but even further down, then you'll have to improve the select statement accordingly.

Does that help?

Happy Reporting,

Nils

PS: The mySysMLModel.mediniGetOpposites('originalModel') does the trick of jumping the proxy barrier from the model/SysMLContainerPackage (AQL sees the resolved one, as in the Attributes view with the button "Resolved" activated) to the proxy.

medini_1061189784

Hi Both,

Thanks for your responses. Your colleague Viktor Tryfelt also assisted with this via email. The solution he suggested was:

{m:for diagram |
projectmodel::PJDiagram.allInstances()}

{m:if diagrams ==diagram.canvasElement}

{m:diagram.asImage().fit(400,400)}

{m:endif}

{m:endfor}

I could then filter for the correct diagrams via:

{m:if
diagram.name.strstr('HMI')}

Seems to have worked.

The only open question I have now is there is a lot of white space between the name of the diagram and the picture.

Is this a limitation of M2Doc?

Thanks

Reece

medini_1059007410

Hi Reece,

Ah, allInstances() was a good hint from Viktor. The "if" is similar to the select - use what is easier to remember for you.

Note that the "==" is not fully correct in AQL (even though it seems to work), actually comparisons are made just by "=".

On the white space: Your listed code does not print the name, but indeed pixel images have some white space around it. You can use "asImage('EMF')" to get a more scalable image, and it does not include (so much, or maybe none at all) whitespace around it.

Cheers,

Nils

medini_1061189784

Hi Nils,

My apologies! This is what the code looks like in report

The white space trick you've described has worked but there still seems to be blank lines inserted into the report:

Any idea?

Thanks

Reece

medini_1024169437

Does it work if you put all the m: statements in one line? Maybe m2doc does not like all these line breaks and spaces between the instructions.

Jan

medini_1059007410

Hi Reece,

The whitespaces originate from the characters plus line breaks you have within your for loop, concretely from the four if/endif lines. Remove the indentation and any whitespaces, then it should work. Keep the line breaks.

To understand what happens: The {m:if} and {m:endif} fields do not result in any text, but Word prints anything, which is around them. If a line is completely empty after replacement of the fields, then Word removes the whole line. But enumerations or indentations do count as some kind of character, so the lines are kept in the output.

So if you want them to disappear, make sure they do not contain any space characters before/after the field(s), and apart from that it is a standard line without any e.g. indentation.

Regards,

Nils

medini_1061189784

Hi Nils

A programmers worse nightmare, no indentation structure!

That has worked though, thank you for your help!

Reece

medini_1024169437

Nils, maybe an article just about these little tweaks would be good, what do you think?

medini_1059007410

Jan,

that's actually already contained in our user guide (I just added the bold+underlined part) :-)

4.2 What happens with M2Doc fields without any output

M2Doc fields are interpreted and replaced by M2Doc during document generation. Some will be replaced by text, some by pictures, but some will not have any output. Comments, conditional statements, or loop statements (except their iftrue or iteration contents) will be replaced by nothing.

Word handles lines (in the .docx template), which contain such M2Doc fields replaced by nothing and are thus after generation completely empty, as follows:

* An empty line is completely removed (note: if leading/trailing spaces, bullets or indentations are present, the line will still be present with these)

* If tables are present above and below the empty line, they are glued together as one table (each with its own column width formatting – make sure they have the same formatting to have the same look, e.g. by not touching column formatting after table splitting)

Cheers,

Nils

medini_1024169437

Awesome, I was blind!

Happy Reporting

Jan