Community
Participate
Working Groups
The Metaabm-editor lets Dynamic Variables be added to Attributes (context menu). This is a bug. Dynamic Variables are only supposed to be added to Agents or Scapes.
Urs, could you add a patch to this bug?
I'm not quite sure how to solve this bug yet. The Attributes element is a selection that does not exist in the EMF tree. That element only exists in the MetaAbm editor. So providing the SD plugin with an "Attributes" selection (as an EObject) does not work. Instead the parent EMF element is being provided. The parent EMF element is an SContext. Now, for an SContext adding Dynamic Variables is a required feature. So I don't think we should change anything in the SD plugins. Instead we should think about how to change the MetaAbm editor. Any suggestions, Miles and Jonas?
Hm... The MetaAbm editor has overwritten standard EMF implementation. As long as possible we should try and keep SD plugins close to EMF standard implementation. That way, any other extension to AMP can be standard. Is there a way to add an EMF representation for "Attributes"? That way we would be able to propagate that selection to ChildCreationExtenders.
Hi guys, It is actually not the case that the EMF editor should always match up to the internal structure of the backing model. That's a kind of difference between say an XSD editor approach. Of course, it would be ideal for this to be the case but it isn't always the best way. For example, remember that actions are not a tree structure at all -- they're actually a DAG -- and there is no way to represent them in generated EMF editor. The EMF editor is designed to be customized and over-ridden, so we should not assume that the editor behavior always follows .genmodel. Here, the default behavior is to make all children of an EObject appear as immediate children in the node. So attributes, rules, and styles would show up in arbitrary order along with everything else -- a real mess. Instead the SAttributedItemProvider wraps the attributes up and delegates them to a custom Attribute provider. Trust me, this wasn't easy to figure out. :) All of this EMF stuff has a very steep learning curve, but as Ed Merks says, steep learning curve is a good thing, it means you can learn to do a lot of things quickly! If you don't have it, you should get a copy of the EMF book 2nd edition -- it covers the editor customization stuff in depth. I'll take a look and see if there is an easy fix. Miles
(In reply to comment #3) > Is there a way to add an EMF representation for "Attributes"? That way we would > be able to propagate that selection to ChildCreationExtenders. Oh yes, I see what you're saying. Yes, I think that having an explicit SAttributeSet makes a ton of sense and would allow us to avoid customization which I would just as soon avoid as well. But.. that's got to be part of the overall new acore transition. I think there are deep issues here as always. We can start thinking about decoupling state/behavior and behavior form agents themselves. But not now! :)
