Do all custom properties have GUIDs?
Do all elements in a domain model including custom properties have by default a GUID assigned I can query? If not how could I do that? Two thoughts:
1) Calculating a custom property value (http://forums.microsoft.com/msdn/ShowPost.aspx?PostID=15445)? If yes, where exactly do I have to implement method "GetValueForCustomStoredAttribute"?
2) Creating a custom property of type GUID and assign the actual GUID at runtime as asked inhttp://forums.microsoft.com/msdn/ShowPost.aspx?PostID=68141?
Cheers,
Alex
[724 byte] By [
AlexWied] at [2007-12-16]
Hi Alex,
I'm not quite clear which meta-level you're working at here.
Do you want:
a) a guid value that represents any type of element that you've defined in your domain model or any valu eproperty on it i.e. a guid->type or guid->member mapping
or
b) a guid that represents an instance of o domain class or relationship in a running designer
Given an example space of a domain model for database design:
an example of (a) would be a guid for the DataTable type and another Guid for the Name property on the DataTable type
The DSL author created these objects.
an example of (b) would be a guid for an instance of DataTable called "Customers" and a different guid for another instance of DataTable called "Orders"
The DSL end-user created these objects.
Hi Gareth, sorry for being unclear. I was referring to (b).
For example, in case of the ConceptA/ConceptB model (that is created by default whenever I create a new DSL project) I compile the domain model, start the a debug instance of Visual Studio and create instances of ConceptB.
Now, I would like to query the GUID of each Concept B instance as well as associations (i.e. links between ConceptB instances), potential fields I add and so forth -- in fact GUIDs for everything I have instances of and that I see in a diagram and/or DSL explorer.
Thanks,
Alex
OK Alex,
What you want is the Id property on any ModelElement. ElementLinks are also ModelElements, so this will work for them.
However, the values of particular Properties on a ModelElement are not themselves ModelElements, so they don't have an instance Id.
So to manufacture a unique string reference to a property value, you'd have to specify the Id of the ModelElement and then the MetaAttributeGuid of the property within the type of the ModelElement.
So, if you have an reference 'baz' to an instance of domain class ConceptA which has a property Foo...
- baz.Id would get you the Guid of the instance
- ConceptA.FooMetaAttributeGuid would get you the guid of the property on the type
Gareth
Hi Gareth,
Just curious why you've chosen not to make attributes model elements? I've been creating MOF models from Rose models where all elements where model elements (or NamedElements) which makes the general treatment of all elements easier IMO.
BTW, just started using the DSL toolkit compared to my MOF experience. The generated metadata classes are alot similar. Is the CounterPart property compareable with Association ?
Are there samples (unit tests) which show the navigability of the meta model(s)?
Grtz, Harry
Hi Harry, I think that decision is probably lost in the mists of time to be quite honest with you. The main reason I'd surmise is to stop the recursion at a clear place, and to more closely match the underlying .Net implementation, where primitive attribute's lifetimes are effectively bounded by their containing objects.
You can find a bit of meta-model navigation inside the code generation templates, specifically the ObjectModelExtras.dsldm file, but we dont' have any further samples at present - we're working on our documentation plan right now.