Community
Participate
Working Groups
Hi, I'd like to propose a small meta model change for JWT. Currently, it is difficult to identify or compare instances of an JWT model. So, would it be possible to introduce Unique Identifiers for JWT elements? The ModelElement of the JWT core package could be the right place for such a change. At the moment, I see no disadvantages for existing applications based on JWT and I think this could help other developers, too. Best Regards Benjamin Honke
I've seen that done in places (e.g. STP BPMN) and while it is very easy to do and use, it can be a mess to work with if you use these ids outside of the workflow model where they are defined, because they introduce strong coupling. In this latter case, it is better to use a **decoupled** way to refer to elements, typically a slashed path like we use in the TaskEngineFramework (1). So it depends whether you want to refer to it within the workflow model (then it's OK, they'd even be valid XML ids), or refer to it from another file (then a decoupled method that uses the workflow structure rather than arbitrary generated ids would be better, and preserve usability across different versions or forks of the same workflow model). (1) see comment of modelElementPath in /jwt-taskengine-api/src/main/java/org/eclipse/jwt/runtime/taskengine/interfaces/ProcessModelService.java : /** * Returns the value of any action - task impl (application, hook...)-specific property. * @param modelName name of process * @param modelElementPath path of action - task tree (including within suprocesses), * consisting in their slash-prefixed names * @param propertyName * @return value with the right Java type (some low-end impls might only return strings) * @throws NoSuchModelElementException if can't find target action - task * @throws NoSuchPropertyException if can't find property on it */ public Object getPropertyValue(String modelName, String modelElementPath, String propertyName) throws NoSuchModelElementException, NoSuchPropertyException;
Update : as Chris said, the requirement is to use completely transient IDs for identification purposes only inside the context of a specific model even to the point where the IDs will change every time the model is loaded (e.g. by calling EcoreUtil.generateUUID() in the ModelElementImpl constructor). So I'm logically perfectly OK with it. Benjamin, you can propose a source patch providing the feature as a zip file attached to this bug, we'll test it, and if it works that'll be good reasons to propose you as committer ! Regards, Marc
Moved version to 1.1 since it still occurs.
