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.

 

So the role end should have an editble list, containing references to properties of the component the role end is connected to.

 

If creating this list is not possible, is it possible to restrict the contents of each role end by means of validation rules?

 

And I still hope to find a way to use object reference and references to the "public properties" of these referenced objects. This principle is used quit heavily in our current (XSD based) DSL.

 

Defining an object in one model, with a set of properties (e.g. required and provided interfaces). In another model a reference to the object can be created, and the properties can als be accessed. In this approach we now need validation to see whether I have selected the right properties, while a query could have restricted the posibilities to those properties that are allowed.

 

With the port approach I woul need to have each input, output or interface to be visually present, while that clutters the picture. especially since I would like to combine several "ports" into one relation. This is possible, but would result in a lot of lines (in general 7 connections from one object) to the relation.

 

I would prefer some other way to connect the properties / related objects of my current object to the relations in the current view.  I still think utopia to be something like: I connect object one with object two and (as with the moveablePortExample) op pups a list with the properties / objectes that can be selected for this relation.

 

But I'm still playing around and learning, so maybe it can be done in a different way...

 

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.