Hide icon in the edition panel

 

 

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

 

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