Value selection from properties

 

To my mind if the components really are intended not to be edited by the modeler (at least not in this model), then its not good to have them contain an editable list of events they support. That's one of the reasons why we don't have such a query mechanism: people start off thinking it would be nice, but realize later that it doesn't offer any real protection, because the list of events at either end could be changed later.

 

Rules to be run on demand are made as normal generators. The user can invoke them manually, and/or you can make other generators invoke them - e.g. before generating code. If you want you can even make them show up as toolbar buttons: just make a generator with a short name starting with an exclamation mark, e.g. !Chk, which calls the generator, and a button to run the generator will appear in the editor toolbar.

 

Rules to be run on the fly are made as generators in symbol elements. You can make a text element whose content comes from a generator, e.g. nothing if everything is OK or some warning text if not. Or you can make a text element that prints the normal content (e.g. the event names), but prints the event name in red if it fails the rule. Or you can make any element (e.g. some kind of error icon) conditional on the output of a generator.

 

Of course in MetaEdit+ you can refer to objects, whether they are directly in the graph or deeper inside some other object. The Component Selection Tool will allow the user to choose where to find eligible objects, e.g. he chooses a graph, then the component, and then sees the events of that component and chooses one of them. The path that he followed is stored in the history, so he can jump straight to that component's list of events again the next time. But the Component Selection Tool doesn't know the path the first time, nor enforce that path.

 

We have played around with the idea of enforcing paths, but there's quite a lot of work for the metamodeler: not just specifying the query, but also the context in which the query can occur. This is sadly tricky in just the cases where such enforcement might be useful, e.g. the properties of a role. When the property dialog opens when creating a new binding, the binding isn't actually created until you press OK (just like with objects), so you can't follow the path to the object to pick up its events :-(. Where the enforcement would affect choices in an object rather than a role, it's even harder: the object could be reused in many different places, so if the object is opened just from a browser (i.e. with no graph context), how to know which context to run the generator from? Of course this is my problem as meta-metamodeler, and your prerogative as metamodeler to just want things to work well for your case, but hopefully this gives you some idea why solving this isn't a slam dunk.

 

I suppose the good news for you is that the utopia you describe is precisely what I've posted in the other thread - although I understand your comments here about multiple ports per relation. You can of course use n-ary relationships, so only the roles at one end will be duplicated. But I think there's something deeper in your actual problem domain that we'd need to look at if you are thinking of having 7 connections per relationship in general.

 

Maybe what you really want are different role types for each component, and in the role type there are checkboxes for each event in that component? That gives you a single relationship for each connection, multiple events/"ports" per connection, selected from the legal set with the minimum of work and maximum of security for the modeler.