Good morning,

I want to ask a question related with metamodeling and the icon representation for objects.

Suppose I have a metamodel and I define a type of object 'A'. For that object, I define a symbol and icon.

After that, in the "Type browser" tab, I include, in my graph type, the object 'A' as a type of object in the metamodel. 

Then, if you open a diagram representation of a graph instance, you can see in the toolbar the icon representation for insert objects 'A' in the graph instance.

My question is, It is possible to hide this icon in the toolbar?. I want that the users can't insert this kind of objects, but I need that it be part of my metamodel (because I want to insert this objects via API)

Thank you in advance

Best regards

 

 

Another approach [in 5.1!] would be to mark the type as Abstract or Hidden, by renaming it _A or __A. Then it will appear in the toolbar etc., but if the user tries to create an instance he will be told it is not instantiable. Rather similar results can be obtained in 5.0 by Remove Type in the Type Browser, but that's probably best reserved for when a type really is removed/obsoleted.

 

All the best,

Steve

Hi

Thanks for the reply,

I'm not sure if it solves what I expect

With the first approach, it works ok, but, if for example I try to get a "Table representation" for the object type "A", it is not possible because it does not appear in the list of candidates.

With the second approach, when I change the name of 'A', from "Object tool", to '__A', for make it hidden, nothing happens. Simply, the name of the type is changed to __A, but nothings change (the object still appears in the toolbar).

With the third approach, I got the same than the first.

Maybe, the second approach is more near to my needs but I don't know if i'm making something wrong.

Thanks

Best regards

 

Of course there are all kinds of interesting questions as to whether it is a good idea to have such "API-only" objects in the model  - but answering that would take a more in-depth understanding of your domain and process than we can achieve in the forum. In general (and not saying anything about your case), I'd say they often look like a good idea to a programmer, but a source of potential problems to a data modeler.

 

If the API-only objects are created to mirror some existing set of components outside MetaEdit+, so that models in MetaEdit+ can use those components, another approach is to create them in MetaEdit+ as types rather than instances (e.g. by importing MXT generated from the components). For instance, if the component is a function marry(man, woman), then you would end up with a type Marry with properties Man and Woman, and an instance might be "Marry man: Charles, woman: Diana", where the properties could be strings, objects etc. depending on the needs. If you later realise you want to include a date of marriage, the type gets updated to have a new date property, and so all instances also have a new empty date (or whatever you set as the default for that property). Using types also neatly solves the issue of stopping users creating new ones - just don't give them metamodeling rights.

 

Of course, using types only works for a subset of all component approaches, and that is only a subset of all cases where you might want an API-only object. Still, it seems a common subset, and does work rather nicely, fitting in well with the idea of DSM.

Thanks for your answer.

Best Regards

 

Exactly, my mistake... It was using the old name. I didn't know nothing about the use of the internal name, but we have parametrized the name of the types in the external tool.

All good except for the "Table representation". Our users will use this representation, for list all the objects "A" on the model. If we call it as "_A" or "__A" it is not possible to view a "Table representation" of "_A" or "__A" objects...

Regards

Thanks for your help

We'll think about the situation carefully, and we'll assess all that you have proposed

Best regards