(get_all_contents_by_type) generates automatic (from simplified_api.capella..) erroneous lines of code

Scripting
1

Hello,
I just noticed that the function (get_all_contents_by_type) could generates erroneous lines of code.
Example here: Writing anywhere in the script
Variable.get_all_contents_by_type(ComponentPort) → will generate this line of code at the beginning of the script:
from simplified_api.capella import ComponentPort
Resulting in this error:

image
image1166×131 6.13 KB

2

Yes imports are done using EASE directive:

include(‘workspace://Python4Capella/simplified_api/capella.py’)

we add an import directive to make PyDev happy but that is never reached at runtime:

if False:
    from simplified_api.capella import *

That a bit hackish but for the moment we have to live with that.

1 Like
3

I will avoid making a thread about this function (get_all_contents_by_type), so I will just use this one, Does the function simply need the attribute “name” of the the value returned by eClass() in aql?
As an example:
Could this:

aql:self.eContents(description::AnnotationEntry)
aql:self.eContents(notation::Diagram)

be replaced with:
Var.get_all_contents_by_type(AnnotationEntry)
Var.get_all_contents_by_type(Diagram)?
Asking because I am fraid “Diagram” could be confused with other classes? Maybe not? (Diagram would always refer to notation::Diagram?)

4

There is a bug in the last release 2022-08-29 with Capella 6.0.0 that cause get_all_contents_by_type() and get_all_contents() to return empty list.

The method get_all_contents_by_type() take a Python class as parameter and the Diagram Python class wrap the Java class DRepresentationDescriptor.

5

Hello
Thank you.
I am well aware of the form of python objects and java objetcs, at least I know (I learned) what functions to apply to each one in every case, and how to iterate in case of python list or java one.
However my question was more about: the second parameter, this one:
image
(The one in red), I was wondering if writing “Diagram” there, will give me (notation::Diagram) items, same for AnnotationEntry. Or if there could be any confusion between “names” of other “classes”.
I guess I could try it to see how it goes. (There are SO MANY things to try with Capella, it can be overwhelming)

6

If you use Diagram here, you will get a list of DRepresentationDresciptor. You can have a look at the Diagram class (or any other class) constructor to see the EClass it reference in the Java world.

def __init__(self, java_object = None):
    """
    """
    if java_object is None:
        JavaObject.__init__(self, create_e_object("http://www.eclipse.org/sirius/1.1.0", "DRepresentationDescriptor"))
    elif isinstance(java_object, Diagram):
        JavaObject.__init__(self, java_object.get_java_object())
    elif get_e_classifier("http://www.eclipse.org/sirius/1.1.0", "DRepresentationDescriptor").isInstance(java_object):
        JavaObject.__init__(self, java_object)
    else:
        raise AttributeError("Passed object is not compatible with " + self.__class__.__name__ + ": " + str(java_object))

notation::Diagram and other GMF notation elements doesn’t exists in the Python simplified API. One idea could be to create this API in a GMF.py file for instance. There is a generator that is probably broken to generate from an .ecore file.

Yes the Capella ecosystem is interconnected with a lot of other tools.