Community
Participate
Working Groups
http://www.eclipse.org/newsportal/article.php?id=3081&group=eclipse.technology.gmf#3081 Suppose I have a model similar to... <Node> <Name>Here goes the name</Name> <Subnode> <SubnodeContent>Here goes the content</SubnodeContent> <Params> <Param>Some arbitrary content here</Param> <Param>Some more content</Param> </Params> </Subnode> </Node> What I want is to have a top-level figure for Node element, with a compartment for Name and another compartment for Subnodes (which can be many). Each Subnode figure in its turn can have zero or more Param children, which should be displayed as labels. What I don't want, is to have a figure for Params container. I'm forced to either create additional (otherwise unnecessary) mapping for Params element in gmfmap model, or provide a "fake" IElementType for it, so that I could reuse CreateElementCommand. On creating a top node it has no structure. Children (and grand-children) are added on user's request, and this is when the structure needs to be initialized. I can prepend CreateElementCommand to create container for new element in the *ItemSemanticEditPolicy. That's why I need IElementType.
Here is a reference for newsreaders: news://news.eclipse.org/e6bad9$q6l$1@utils.eclipse.org This is a feature for next version.
With mapping like this: NodeMapping - Node ChildReference - containmentFeatureParam NodeMapping - Param you'll need to (a) ignore validation, (b) fix compilation issues. As long as you need some additional code to handle container creation, this should not be a problem. We'll definitely address these to some extent (perhaps, some sort of markers pointing to exact place inside code that requires attention, instead of validation errors). Though, I doubt out-of-the-box solution for such usecase could be reasonably simple. In general, one needs to distinguish 'children' *selector* from 'containment' (which is the theme of this bugzilla) - e.g. imagine Subnode has non-cont. reference to Param to display inside Node (thus, ChildReference's childrenFeature may look like subnode/referencedParam), while creation should take place in subnode/params/param feature. In addition, 'containment' selector might have need to specify whether to create intermediate containers or not (and what if containers feature is multiple - should we use existing value - which one? - or just add another one?). To me, it sounds like a really complex syntax and I'd be grateful for ideas how to make it reasonable while keeping it useful.
The solution you describe is exactly how I currently approach this issue. Nothing is terribly wrong with it, only when I face the necessity to actually create "Params" container with CreateElementCommand I must introduce a IElementType for it. I don't know, there may be other ways to create a container without the IElementType, in which case this is no longer an issue. Please, don't exaggerate the problem discussed here. The XML structure I described is a very simple idea, and is a quite common pattern indeeed. Basically, "Params" serves *only* the purpose to group together "Param" elements. They could have just been moved to "Subnode", in which case Subnode.params feature would be sufficient. EMF could probably have built-in support for this scenario (and it might have actually, I just don't know; I'm using the ecore model generated from XSD). So, in case there is an alternative approach, I would be more than willing to switch to it and withdraw this request altogether. Otherwise, I would suggest to use a very simple strategy here: create new "Params" container for any "Param" elements created and (optionally) destroy an empty "Params" after its last child has been destroyed.
I'm experiencing a similar problem. However, in 2.0 I find that the proposed workaround (ignore errors in gmfmap and gmfgen and fix resulting compile errors) no longer works. The code generation throws exceptions and does not complete. I have had some success with tweaking the jet templates to tolerate the lack of Children Feature and/or Containment Feature in a Child Reference. In such cases I've been generating a stub method that I can fill in later to do the creation (or selection of existing element) the way I want. There are also some changes to the generation of code to delete such elements. What would you think of making the ChildrenFeature and ContainmentFeature optional, and when they are not specified the toolsmith names his own commands to create, delete, move that kind of element instead?
(In reply to comment #4) Templates should tolerate absence of these features. I've submitted bug #181771 to cover codeneration aspect of the problem.
Updated target milestone
*** Bug 221542 has been marked as a duplicate of this bug. ***
Bulk update, target milestone 2.2
[GMF Restructure] Bug 319140 : product GMF and component Generation was the original product and component for this bug
