ThingShape property name clash with ThingTemplate

[rtaylor-3]

We are creating an application where participating assets must have certain properties and behavior.

Currently we achieve this by creating a ThingShape which exposes the required properties and behavior in the hopes that any customer with existing assets wishing to participate would simply have their own asset template extend the ThingShape.

However, I'm concerned if their existing asset template already contains any properties on our ThingShape (name clash), then Composer will not allow the template to implement the shape.

Therefore, in order for their assets to participate, they would have to modify their template such that there is no name clash or create a separate template.

We don't want to force the end user to use our ThingTemplate because then they couldn't leverage their current assets "as-is".

Is there a work around here?

[CarlesColl]

Hi Robert,

This situation also applies to events and services, also applies to ThingTemplates, you can interfere with existing properties, events and services for them too.

I stablished a way to name events, services and properties on my project, I've checked different ways of doing it, and for me the best option was suffixing the Entity name after the event, service or property. Something like:

Let's say we have a ThingShape called, MyThingShape, and we want to add a property called myProperty1, we will not name it myProperty1, we will name it myProperty1_MyThingShape. Same applies to ThingTemplates events, services and properties.

I've suffixed it in order to let the composer show first the property name instead of the entity name which it's already shown on top.

To separate name and entity I've used "_" but you can use also "-".

Your concerns are right, and you should start using this can of naming convention, also if you have to integrate with third party projects you can have integrations problems, here it starts the naming conventions for entities itself

All this should be on a Best Practices document, I've already written one internally for us.

Best Regards,

Carles.

[CarlesColl]

Well the problem you will face with this naming convention will be that you can't use anymore the raw propertyNames as for the User Interface, as they start to be awful. Here it's where starts the need for the PropertyName localization support...