Home » Modeling » GMF (Graphical Modeling Framework) » multiple creation tools mapping to a single domain element
multiple creation tools mapping to a single domain element [message #165818] |
Wed, 19 December 2007 00:10 |
sam Messages: 20 Registered: July 2009 |
Junior Member |
|
|
Hi, there,
In my application, there is a service element defined in the domain model.
During the run time, multiple instances of this service element will
populate from some external provider with different field values. Each
service instance corresponds a creation tool in the palette, which is also
dynamically populated. Since everything is dynamically populated, I can
not use the GMF tutorial sample (Connection type), which is statically
defined in the model.
My question is what's the best approach to solve this problem. Is that
possible to solve this problem through model/graph/map? or only through
programming, how?
By the way, I tried to statically define multiple mapping to a single
domain elements first. That is, I defined multiple creation tools mapping
to the same graphical node and the same domain element (service). However,
when I put them on the canvas, they won't show up until I create or move
some other diagram. I wonder if this is the problem mentioned in GMF
tutorial part 2:
"In fact, whenever you create multiple mappings to a single domain
element, you will need to add constraints such that each can be uniquely
identified."
However, I can not make the similar constrains ('self.type =
RelationshipType::EXTENDS') because I can't statically define the
instances of service in the domain model. Any idea?
Any suggestion or hint will be greatly appreciated!
Sam
|
|
|
Re: multiple creation tools mapping to a single domain element [message #165899 is a reply to message #165818] |
Wed, 19 December 2007 12:59 |
Boris Blajer Messages: 217 Registered: July 2009 |
Senior Member |
|
|
Hi Sam,
> By the way, I tried to statically define multiple mapping to a single
> domain elements first. That is, I defined multiple creation tools
> mapping to the same graphical node and the same domain element
> (service). However, when I put them on the canvas, they won't show up
> until I create or move some other diagram. I wonder if this is the
> problem mentioned in GMF tutorial part 2:
>
> "In fact, whenever you create multiple mappings to a single domain
> element, you will need to add constraints such that each can be uniquely
This is a likely cause of the problem.
> However, I can not make the similar constrains ('self.type =
> RelationshipType::EXTENDS') because I can't statically define the
> instances of service in the domain model. Any idea?
>
If you set the language property of the constraint to Java, GMF will
generate method stubs for you to implement, which will allow dynamic
service resolution. Do not forget to mark the methods as @generated NOT
so that the method bodies are not sweeped off upon regeneration. You
will probably also need to define element initializers so that they pass
the constraint upon creation. Initializers may also specify the Java
language.
Best regards,
Boris
|
|
|
Re: multiple creation tools mapping to a single domain element [message #165997 is a reply to message #165899] |
Wed, 19 December 2007 17:27 |
Stefan Kuhn Messages: 355 Registered: July 2009 |
Senior Member |
|
|
by the way boris, why don't you guys make a srcCustom folder when
creating a gmf model? So you could call a
XXXVisualRegistryConstraintsImpl in the generated code: which would act
as a mock object and would help splitting gen-code and custom code?
-stefan
Boris Blajer wrote:
> Hi Sam,
>
>> By the way, I tried to statically define multiple mapping to a single
>> domain elements first. That is, I defined multiple creation tools
>> mapping to the same graphical node and the same domain element
>> (service). However, when I put them on the canvas, they won't show up
>> until I create or move some other diagram. I wonder if this is the
>> problem mentioned in GMF tutorial part 2:
>>
>> "In fact, whenever you create multiple mappings to a single domain
>> element, you will need to add constraints such that each can be uniquely
> This is a likely cause of the problem.
>
>> However, I can not make the similar constrains ('self.type =
>> RelationshipType::EXTENDS') because I can't statically define the
>> instances of service in the domain model. Any idea?
>>
> If you set the language property of the constraint to Java, GMF will
> generate method stubs for you to implement, which will allow dynamic
> service resolution. Do not forget to mark the methods as @generated NOT
> so that the method bodies are not sweeped off upon regeneration. You
> will probably also need to define element initializers so that they pass
> the constraint upon creation. Initializers may also specify the Java
> language.
>
> Best regards,
> Boris
|
|
|
Re: multiple creation tools mapping to a single domain element [message #166005 is a reply to message #165997] |
Wed, 19 December 2007 18:18 |
sam Messages: 20 Registered: July 2009 |
Junior Member |
|
|
Thank you very much for the help, Boris!
I tried your approach and got two questions now:
First question, whenever I add "constraint" to "gmfmap", I can't run the
auto generated diagram plug-in (there is no compiler error in it). The
error message is:
Missing required bundle org.eclipse.ocl.ecore_0.0.0.
However, the plug-in "org.eclipse.ocl.ecore" is in the auto generated
diagram plug-in's dependencies. Also I don't think it's my Eclipse's
problem because I can run "Mindmap" application with "constraint". In
fact, I didn't use "ocl" at all, I specify "java" in both "constraint" and
"feature sequence initializer".
Second question, should I leave the body of "constraint" as blank or not?
If it's blank, the "gmfgen" has an error mark, although I can still
generate diagram plug-in. If not blank, what should I write? Is there any
information/source code about "java" constraint I can take a look?
By the way, I like stefan's idea.
Thanks again!
Sam
|
|
| |
Re: multiple creation tools mapping to a single domain element [message #166021 is a reply to message #166005] |
Wed, 19 December 2007 19:10 |
Boris Blajer Messages: 217 Registered: July 2009 |
Senior Member |
|
|
Hi Sam,
> First question, whenever I add "constraint" to "gmfmap", I can't run the
> auto generated diagram plug-in (there is no compiler error in it). The
> error message is:
> Missing required bundle org.eclipse.ocl.ecore_0.0.0.
> However, the plug-in "org.eclipse.ocl.ecore" is in the auto generated
> diagram plug-in's dependencies. Also I don't think it's my Eclipse's
> problem because I can run "Mindmap" application with "constraint". In
> fact, I didn't use "ocl" at all, I specify "java" in both "constraint"
> and "feature sequence initializer".
It is a bit strange that this prerequisite is added. As a workaround,
simply delete this prerequisite from manifest.mf manually and see if you
can run it.
>
> Second question, should I leave the body of "constraint" as blank or
> not? If it's blank, the "gmfgen" has an error mark, although I can still
> generate diagram plug-in. If not blank, what should I write? Is there
> any information/source code about "java" constraint I can take a look?
Well, if the language is "java", this value is not used (so leaving it
blank should work as well as typing any garbage there). Please submit a
bug report that blank values should not lead to validation problems if
the language is "java".
Best regards,
Boris
|
|
| |
Re: multiple creation tools mapping to a single domain element [message #166048 is a reply to message #166013] |
Wed, 19 December 2007 23:15 |
Stefan Kuhn Messages: 355 Registered: July 2009 |
Senior Member |
|
|
hi boris,
I'm not sure if a single aspect -like a constraint- should be customized
by modifying the template because:
a) it's harder to find the right template (comments from where the code
is generated are missing) and more native for the programmer to code it.
b) a single constraint like isAbcObject would mean checking in the
template for a special -single- situation
c) ok, this could be realized by xPands aspects, but it's far easier to
loose the point what's really executed with aspects.
d) I wonder if it's not better to customize by extension points in
another bundle.
-stefan
Boris Blajer wrote:
> Hi Skuhn,
>
> The "preferred" way of customizing the generated code is to use dynamic
> templates, not to modify the generated code manually with @generated NOT's.
> I am not sure these two approaches fit together... However, you may
> submit an enhancement request, at least to specify and discuss
> requirements for your suggestion.
>
> Best regards,
> Boris
>
> SKuhn wrote:
>> by the way boris, why don't you guys make a srcCustom folder when
>> creating a gmf model? So you could call a
>> XXXVisualRegistryConstraintsImpl in the generated code: which would act
>> as a mock object and would help splitting gen-code and custom code?
>>
>> -stefan
>>
|
|
|
Re: multiple creation tools mapping to a single domain element [message #166056 is a reply to message #166048] |
Wed, 19 December 2007 23:19 |
Stefan Kuhn Messages: 355 Registered: July 2009 |
Senior Member |
|
|
oh, I forgot to mention that it's nice that you can extend Gmfgen, but
sadly you can't extend the mapping model.
SKuhn wrote:
> hi boris,
>
> I'm not sure if a single aspect -like a constraint- should be customized
> by modifying the template because:
> a) it's harder to find the right template (comments from where the code
> is generated are missing) and more native for the programmer to code it.
>
> b) a single constraint like isAbcObject would mean checking in the
> template for a special -single- situation
>
> c) ok, this could be realized by xPands aspects, but it's far easier to
> loose the point what's really executed with aspects.
>
> d) I wonder if it's not better to customize by extension points in
> another bundle.
>
> -stefan
>
>
> Boris Blajer wrote:
>> Hi Skuhn,
>>
>> The "preferred" way of customizing the generated code is to use dynamic
>> templates, not to modify the generated code manually with @generated NOT's.
>> I am not sure these two approaches fit together... However, you may
>> submit an enhancement request, at least to specify and discuss
>> requirements for your suggestion.
>>
>> Best regards,
>> Boris
>>
>> SKuhn wrote:
>>> by the way boris, why don't you guys make a srcCustom folder when
>>> creating a gmf model? So you could call a
>>> XXXVisualRegistryConstraintsImpl in the generated code: which would act
>>> as a mock object and would help splitting gen-code and custom code?
>>>
>>> -stefan
>>>
|
|
|
Re: multiple creation tools mapping to a single domain element [message #166065 is a reply to message #166056] |
Thu, 20 December 2007 10:05 |
Boris Blajer Messages: 217 Registered: July 2009 |
Senior Member |
|
|
Hi Stefan,
> oh, I forgot to mention that it's nice that you can extend Gmfgen, but
> sadly you can't extend the mapping model.
Well, our idea was that you may write your own instead. There should be
one gmfgen model only, because the templates are too tightly coupled to
it. But there can be an arbitrary number of "mapping" models, each with
its own transformer.
We already support the sketch model and transform it into the gmfgen
model. There are plans to have "extended" mapping models in order to
support some advanced features with their own transformations into the
common gmfgen format.
>
>>
>> I'm not sure if a single aspect -like a constraint- should be customized
>> by modifying the template because:
>> a) it's harder to find the right template (comments from where the code
>> is generated are missing) and more native for the programmer to code it.
>>
>> b) a single constraint like isAbcObject would mean checking in the
>> template for a special -single- situation
>>
>> c) ok, this could be realized by xPands aspects, but it's far easier to
>> loose the point what's really executed with aspects.
>>
>> d) I wonder if it's not better to customize by extension points in
>> another bundle.
>>
Yes, I agree that for this very case (constraints written in Java)
dynamic templates make little sense. In fact, that was the reason why I
encouraged you to submit the request: because we need to define in which
situations this approach works better than the one with template
modification.
Best regards,
Boris
|
|
|
Goto Forum:
Current Time: Wed Apr 24 18:31:42 GMT 2024
Powered by FUDForum. Page generated in 0.04425 seconds
|