Convenience wrapper for (input/output) locations of specific integration node types

[rfahlberg]

📝 Description of the feature

Currently, users are able to register input/output locations of integration nodes using register_location_as_... methods. The location argument is a generic structure. Users need to know the structure.

As an enhancement, add convenience functionality/wrappers for specific integration nodes, to support users in creating the location descriptions.

Priority list for specific integration nodes:

• Python-based integrations (subtype=AddinType.PYTHON_BASED_INTEGRATION_PLUGIN)
• Parameterize node(s)
• ETK nodes
• Ansys optiSLang node
• Python node
• Excel node
• Matlab node

💡 Steps for implementing the feature

No response

🔗 Useful links and references

No response

[PanekOndrej]

Location types differ quite a lot even across mentioned nodes, only Python-based integrations seem to have common structure. I propose to create class LocationRegister that will implement registration of location in more convenient way than current methods.
This register would be specific to each node and would be defined as optional argument in NodeType constant (similarly as osl_class_type). Structure below:

class LocationRegister(ABC):

• register_variable_as_response(*this may be common I think)
• some getter methods, like input location count

class PythonBasedIntegrationLocationRegister(LocationRegister):

• __init__(uid: str, osl_server: OslServer)
• register_location_as_parameter(*arguments specific for the python based intergrations locations)
• register_location_as_response(*arguments specific for the python based intergrations locations)
• register_location_as_variable(*arguments specific for the python based intergrations locations)

*Please note that register_location_as_xxx arguments reflect the location structure and are specific to each node type.

*We could also create some LocationType data classes to return user information about already registered locations (and potentially use this format to register new locations as well as some nodes support get_available_locations() query). These location types would have to be specific for each node too. It would allow to have all methods of location register in format:

• register_location_as_parameter(location: LocationType)

For example, location register for ETK node would not implement register_location_as_parameter.

Issues:

• python based integrations can be set to input/solver/output only

What do you think @rfahlberg?