Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jwt-dev] add unique ID to meta model?

Hi guys,

I don't see any issues to this addition. Go ahead!

Best regards,


-----Ursprüngliche Nachricht-----
Von: jwt-dev-bounces@xxxxxxxxxxx [mailto:jwt-dev-bounces@xxxxxxxxxxx] Im
Auftrag von Marc Dutoo
Gesendet: Freitag, 26. November 2010 16:33
An: jwt-dev@xxxxxxxxxxx
Betreff: Re: [jwt-dev] add unique ID to meta model?

Stupid me, I didn't even see the "transient" part...
OK, seems like a nice addition !

Benjamin, once it's done we'll use that to get you to committer status, 
not yet Christmas and already gifts there :)

Actually, I didn't see the bug because I wasn't on the metamodel 
Bugzilla CC list.

& I've added all that on the bug.


Le 26/11/2010 15:59, Christian Saad a écrit :
> Hi Marc,
> if I understand the request correctly, 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).
> Regards,
> Chris
> Am 26.11.2010 15:26, schrieb Marc Dutoo:
>> Hi
>> I understand the need very well.
>> However, 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).
>> Regards,
>> Marc
>> (1) see comment of modelElementPath in
>> :
>> /**
>> * 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;
>> Le 25/11/2010 17:24, Christian Saad a écrit :
>>> Hi all,
>>> my collegue Benjamin files a bug for including some kind of
>>> identification mechanism for model elements in the form of a transient
>>> ID attribute (see bug 329262). The requirement behind this is to make
>>> each element of the loaded model uniquely identifiable so it can be
>>> easily tracked.
>>> Since this is probably a fairly unintrusive and easy to implement
>>> change, I'd like to ask if you would be ok with this. Basically it
>>> would boil down to adding an ID attribute to ModelElement which would
>>> not be visible (e.g. in the property view) nor be serialized into the
>>> workflow file.
>>> Please let me know what you think.
>>> Regards,
>>> Chris
>>> _______________________________________________
>>> jwt-dev mailing list
>>> jwt-dev@xxxxxxxxxxx
>> _______________________________________________
>> jwt-dev mailing list
>> jwt-dev@xxxxxxxxxxx
> _______________________________________________
> jwt-dev mailing list
> jwt-dev@xxxxxxxxxxx

jwt-dev mailing list

Back to the top