Storing plugin specific data in the EA model

[Mike Chapman]

I would like to store some application specific data in an EA model.  It is to be used by our plugin and ideally would not be seen or editable by users.

I thought that tagged values would be a reasonable mechanism to use (I realize that they are in fact visible and editable, so we'll give them ugly and obscure names), since they can be found on Elements and Attributes.  They are also available on Packages, via that special Packages.Element interface that finds the 'special' Element associated with a Package (the one that has the same GUID as the Package).

But for some reason, Package.Element is always NULL on the top level Model packages.  Ironically, that is the first place that I want to store something in.  

I don't think that I can force the creation of one of these Elements, as I'd need to set the GUID to be the same as the associated Package, and the typical Collection.AddNew() would not work because they're not in a collection, just a single reference.

So my question is... can I make EA create an Element on Model packages?  Or is there a better, more elegant (to be honest, I'd settle for reliable) way to store application data in an EA model?


Edit:  Strange, I notice that on the top level Models (visually the top level ones in the Package Explorer), you are not able to set any properties, even through the GUI... like Notes, etc. I don't even see 'Properties' on the context menu for the top level models.

I have a feeling that this restriction is somehow related to the one I'm seeing in the automation interface.  Why not allow folks to set properties at the top level?  I think I'm missing something basic here.

[Geert Bellekens]

Mike,

A solution to the issue of the root packages is to create one "root" and nest all existing root packages into this one.

Geert

[Mike Chapman]

Interesting idea!

I could require users to create their models in this way.  Not super friendly.

Or I could create and maintain this ubermodel myself.  

I don't suppose that this could be done invisibly, eh?  The users will see the reorganization, which could surprise them.

Now you've got me thinking about generating stuff in the model to store metadata.  Another possibility would be to create a separate top level model with a sub-project, which would have an associated element, and that's where I could add my tagged values.  At the cost of one out-of-tree visual wart, I can store data and the user's models are unaffected.  

I don't have any experience with real Sparx users, which idea do you think would be less annoying/disruptive?