Autocomplete and Validate of a String based on Enum and Other concept properties


I have a concept with a string property I need to autocomplete and validate based on two sources of allowed values.

1) A static list of three items (Can be Enum or whatever is best)
['energy', 'shape', 'color']

2) List of all attributes assigned to other 'entity' concepts in the editor. Example
Concept entity 'Human' has Attributes as children and these Attributes has a name property.

I need to merge these two in a way, and allow only the static list and the custom list of the attributes.
I this possible?

I think I can do the validation part as part of the constraints, but not sure about the autocomplete.



1 comment
Comment actions Permalink

There are several ways I can think of to achieve this, in the end, you would have to try them out to see what works best for your specific use case.

Approach 1: A Concept with two extensions

You want to unify references to something (Attributes of other entities) and a static (right?) list of predefined, possible values. You can create an abstract concept / interface concept (AttributeRefOrStaticVal) and create two extensions of that concept, one being a smart reference to your Attributes, one being just a container for a string property.

For usability, you can then create a custom substitution menu so that the user can include nodes without having to explicitly chose between the concept extensions first, if that is important to you.

Approach 2: A string property with a menu part

Structurally lighter, you can just have a string property and provide it with a menu (in the inspector of its editor cell) that calculates all possibilities (unifies the static values and the current references). I think this should also already highlight invalid values as wrong.

Read at least a little about property menues here:

Biggest downside is that this means that you have to build the scope manually and that the "references" to the user-defined Attributes are not really references and break if the source changes.

Approach 3: Smart Reference with Accessory Model

You can just use a smart reference and have an accessory model in your language that provides your static values.


I would most likely go for the third option based on what I know by now, it isstructurally the cleanest and very easy to extend.


Please sign in to leave a comment.