Open flongford opened 4 years ago
Something like:
#: Identifies a CUBA type with its key.
CUBAType = String()
class CUBATypeMixin(HasStrictTraits):
#: A CUBA key describing the type of the parameter
type = CUBAType('Value', visible=False)
def get_ontology_attribute(self):
"""Return the OntologyAttribute for an CUBAType trait"""
The following code could be used to get a reference to the CUDS ontology class for a CUBAType
correctly formatted string.
from osp.core import get_entity
# Create some instance of a class that inherits CUBATypeMixin
data_value = CUBATypeMixin(type='my_namespace.my_attribute`)
# Look up the CUDS class associated with that string
entity = get_entity(data_value.type)
# Obtain the python data type associated with this class
data_type = entity.datatype
However, if the entity
variable is a complex object with no associated datatype
, then an error will be raised. If we just wish to attempt to look up the expected basic python type of a particular class, then we could simply handle this exception accordingly.
At the moment our
CUBAType
traits are unformatted strings that act as placeholders to reference objects in anosp-core
ontology. It is expected that they would match up to anOntologyAttribute
object, which also defies the python basic data type, and holds an internal reference to theOntologyNamespace
that it resides in.Therefore we should develop a method to allow either:
CUBAType
trait to be of typeOntologyAttribute
OntologyNamespace
in theCUBAType
string formatting (i.e.'my_namspace.my_attribute'
. An internal method should then be able to parse this string and 'lookup' theOntologyAttribute
object(This system resembles string references to python modules)
It is also important not to break any existing implementations of the
CUBAType
trait if possible. So far none of our plugins would contain string values that contain references to an ontology namespace. The 'lookup' act should be optional at first, whilst depreciating the unformatted strings, before removing them in a later version.