A businesselement shold be attachable to Diagrams

[GoogleCodeExporter]

It should be possible to attach a buisinesselemen to the diagram itself similar 
to MetaClasses. e.g.

class Model:
    diagram(<<some properties>>) [       
]

This is needed for a well structured semantic model and if DrillDownFeatures 
should be supportable at any time.

Original issue reported on code.google.com by veit.hof...@googlemail.com on 4 Nov 2011 at 8:30

[GoogleCodeExporter]

I fully agree that this should be possible.

Original comment by joswar...@gmail.com on 5 Nov 2011 at 4:20

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

The question is whether this should be done in the DSL , or in the manual 
extension code. Need to try out how this can be sued.

Original comment by joswar...@gmail.com on 5 Nov 2011 at 4:24

• Changed state: Accepted

[GoogleCodeExporter]

Veit will provide a sample implementation for example.one

Original comment by karsten....@googlemail.com on 7 Nov 2011 at 11:18

[GoogleCodeExporter]

This must be a property of the diagram. The project wizard must also offer to 
specify the model element type.

I am thinking the DSL to look like this:

   diagram mydiagram for MyModel

It is also necessary to know the model type to offer containment references for 
create features.

To shorten the names for the root element type the import statements must occur 
before the 'diagram' keyword:

{{{
   import BusinessDomainDsl.*
   diagram mod4j for BusinessDomainModel // imported
}}}

Original comment by karsten....@googlemail.com on 14 Nov 2011 at 9:33

• Changed state: Started

[GoogleCodeExporter]

Committed changes for DSL, Metamodel, Scoping, Templates

The implementation code has to create the Model element now and add created 
elements to it now.

Original comment by karsten....@googlemail.com on 15 Nov 2011 at 5:41

[GoogleCodeExporter]

I like this change.  A question:  should we make it mandatory that a diagram 
alkways represents one Domain model type ?  I think this certainly is good 
style and makes it much easier to define editors with Graphiti / Spray.
I am in favor of making this mandatory.

Original comment by joswar...@gmail.com on 15 Nov 2011 at 11:41

[GoogleCodeExporter]

At the moment it is mandatory, I was thinking the opposite way around: Should 
it be possible that it is optional?

The project wizard inforces you now to choose a root element type. I have 
preparations pending that the model element is created and elements created 
into a given containment reference. I think this can make it this week.

See issue#60 for this.

Original comment by karsten....@googlemail.com on 15 Nov 2011 at 11:57

[GoogleCodeExporter]

I strongly advice not to do this (saves you work as well :-) . It is a sensible 
restriction to ensure that the diagram always has one Domain element connected 
at the root. From my experience with using Graphiti / Spray I do have seen that 
not having a root Domain element for a diagram will make life much more complex 
at many places. 
E.g. solutions for issue 
http://code.google.com/a/eclipselabs.org/p/spray/issues/detail?id=60  will 
become more complex,  as the context in which to add becomes even more unclear 
and more difficult to find.

Original comment by joswar...@gmail.com on 15 Nov 2011 at 12:08

[GoogleCodeExporter]

OK for me. It makes the code also more concise.

Original comment by karsten....@googlemail.com on 15 Nov 2011 at 12:14

[GoogleCodeExporter]

Sorry I was very busy last week. Do you still need an example implementation 
for example.one

Original comment by veit.hof...@googlemail.com on 15 Nov 2011 at 1:23

[GoogleCodeExporter]

Introduced a ModelService template: The ModelService class is responsible for 
creating the model root and attaching it to a new resource
The URI of the model instance is stored in the diagram for later fetching
Changed the create feature to add an element to its containment reference.

As a further bonus, the model is not saved instantly anymore. Instead the 
diagram is marked dirty after element creation. If the domain model file does 
not exist, it will be created on saving.

Original comment by karsten....@googlemail.com on 15 Nov 2011 at 11:26

• Changed state: Fixed

[GoogleCodeExporter]

@Veit: You may have a look at the new implementation. Does this now fit your 
requirements?

Original comment by karsten....@googlemail.com on 15 Nov 2011 at 11:28