Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » first create classes then move them into package
first create classes then move them into package [message #431622] Sun, 19 July 2009 09:10 Go to next message
Eclipse UserFriend
Originally posted by: formatzeh.gmx.de

I'm speaking about the Ecore Diagram Editor. I created some ecore
classes and put them into relation. Now I decided that it would be
better to add some packages just because of SoC. Well it's not so easy
as I thought. I added the package in the diagram but I couldn't find a
way to move some classes into it. My first try was to select the package
-> format -> order -> send to back. But the result was only visual.
Another try was to drag&drop the classes into the package but the result
was that in the package only references of the classes appeared and the
classes stayed in its old place. How is it possible?
What else is interesting for me is what is the purpose of packages in an
ecore model? I mean there is the SoC purpose. But what else? My aim is
to generate an editor. Is it possible to generate several editors? For
every package its own? And they must work on the same model i.e. on the
same file. It would be nice because than every gmf editor can have its
own graphical notations.

regards
Gilbert
Re: first create classes then move them into package [message #431623 is a reply to message #431622] Sun, 19 July 2009 09:42 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6457
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------050406020805070104060507
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Gilbert,

Comments below...


Gilbert Mirenque schrieb:
> I'm speaking about the Ecore Diagram Editor.
That makes me think that the EMFT newsgroup is more likely to give good
support on EcoreTools.

> I created some ecore
> classes and put them into relation. Now I decided that it would be
> better to add some packages just because of SoC.
Technically it's possible to add subpackages to an EPackage but the cool
guys don't do it. Often it's better to factor out separate modules, i.e.
own model plugins.

> Well it's not so easy
> as I thought. I added the package in the diagram but I couldn't find a
> way to move some classes into it. My first try was to select the package
> -> format -> order -> send to back. But the result was only visual.
> Another try was to drag&drop the classes into the package but the result
> was that in the package only references of the classes appeared and the
> classes stayed in its old place. How is it possible?
>
This looks like an EcoreTools question and should be asked in the EMFT
newsgroup.

> What else is interesting for me is what is the purpose of packages in an
> ecore model? I mean there is the SoC purpose.
A pity that a (package) tree is not particularly well-suited for the
separation of multiple concern dimensions.

> But what else? My aim is
> to generate an editor. Is it possible to generate several editors? For
> every package its own?
IIRC. editors are generated for models and not for single packages
therein. But I always recommend against generating model-specific
editors at all! IMHO model-specifics should be isolated in the generated
model plugin or in the generated edit plugin. Editors should be
UI-specific, if that's needed at all. If you compare any two generated
editors you'll notice that they really only differ in the registration
of package-specific ItemProviderAdapterFactories in the
initializeEditingDomain() method. With the following replacement of that
code you get a truely generic editor:

| ComposedAdapterFactory.Descriptor.Registry registry = EMFEditPlugin.getComposedAdapterFactoryDescriptorRegistry();
adapterFactory = *new *ComposedAdapterFactory(registry);
adapterFactory.addAdapterFactory(*new *ResourceItemProviderAdapterFactory());
adapterFactory.addAdapterFactory(*new *ReflectiveItemProviderAdapterFactory());|




> And they must work on the same model i.e. on the
> same file. It would be nice because than every gmf editor can have its
> own graphical notations.
>
Generally EMF Transaction or the CDO Model Repository offer
transactionality and multi user characteristics, although they do it
quite differently. It could make sense to ask the GMF newsgroup for more
infos on how they do it.

Cheers
/Eike

----
http://thegordian.blogspot.com
http://twitter.com/eikestepper



--------------050406020805070104060507
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Gilbert,<br>
<br>
Comments below...<br>
<br>
<br>
Gilbert Mirenque schrieb:
<blockquote cite="mid:h3unuu$4vo$1@build.eclipse.org" type="cite">
<pre wrap="">I'm speaking about the Ecore Diagram Editor. </pre>
</blockquote>
That makes me think that the EMFT newsgroup is more likely to give good
support on EcoreTools.<br>
<br>
<blockquote cite="mid:h3unuu$4vo$1@build.eclipse.org" type="cite">
<pre wrap="">I created some ecore
classes and put them into relation. Now I decided that it would be
better to add some packages just because of SoC. </pre>
</blockquote>
Technically it's possible to add subpackages to an EPackage but the
cool guys don't do it. Often it's better to factor out separate
modules, i.e. own model plugins.<br>
<br>
<blockquote cite="mid:h3unuu$4vo$1@build.eclipse.org" type="cite">
<pre wrap="">Well it's not so easy
as I thought. I added the package in the diagram but I couldn't find a
way to move some classes into it. My first try was to select the package
-&gt; format -&gt; order -&gt; send to back. But the result was only visual.
Another try was to drag&amp;drop the classes into the package but the result
was that in the package only references of the classes appeared and the
classes stayed in its old place. How is it possible?
</pre>
</blockquote>
This looks like an EcoreTools question and should be asked in the EMFT
newsgroup.<br>
<br>
<blockquote cite="mid:h3unuu$4vo$1@build.eclipse.org" type="cite">
<pre wrap="">What else is interesting for me is what is the purpose of packages in an
ecore model? I mean there is the SoC purpose. </pre>
</blockquote>
A pity that a (package) tree is not particularly well-suited for the
separation of multiple concern dimensions. <br>
<br>
<blockquote cite="mid:h3unuu$4vo$1@build.eclipse.org" type="cite">
<pre wrap="">But what else? My aim is
to generate an editor. Is it possible to generate several editors? For
every package its own? </pre>
</blockquote>
IIRC. editors are generated for models and not for single packages
therein. But I always recommend against generating model-specific
editors at all! IMHO model-specifics should be isolated in the
generated model plugin or in the generated edit plugin. Editors should
be UI-specific, if that's needed at all. If you compare any two
generated editors you'll notice that they really only differ in the
registration of package-specific ItemProviderAdapterFactories in the
initializeEditingDomain() method. With the following replacement of
that code you get a truely generic editor:<br>
<br>
<title></title>
<style type="text/css">
<!--code { font-family: Courier New, Courier; font-size: 10pt; margin: 0px; }-->
</style>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<!-- ======================================================== -->
<!-- = Java Sourcecode to HTML automatically converted code = --><!-- = Java2Html Converter 5.0 [2006-02-26] by Markus Gebhard markus@jave.de = -->
<!-- = Further information: http://www.java2html.de = -->
<div class="java" align="left">
<table bgcolor="#ffffff" border="0" cellpadding="3" cellspacing="0">
<tbody>
<tr>
<!-- start source code --> <td align="left" nowrap="nowrap"
valign="top"> <code><font color="#ffffff">    </font><font
color="#000000"> ComposedAdapterFactory.Descriptor.Registry registry = EMF EditPlugin.getComposedAdapterFactoryDescriptorRegistry </font><font
color="#000000">()</font><font color="#000000">;</font><br>
<font color="#ffffff">    </font><font color="#000000">adapterFactory = </font><font
color="#7f0055"><b>new </b></font><font color="#000000">ComposedAdapterFactory</font><font
color="#000000">(</font><font color="#000000">registry</font><font
color="#000000">)</font><font color="#000000">;</font><br>
<font color="#ffffff">    </font><font color="#000000">adapterFactory.addAdapterFactory</font><font
color="#000000">(</font><font color="#7f0055"><b>new </b></font><font
color="#000000">ResourceItemProviderAdapterFactory</font> <font
color="#000000">())</font><font color="#000000">;</font><br>
<font color="#ffffff">    </font><font color="#000000">adapterFactory.addAdapterFactory</font><font
color="#000000">(</font><font color="#7f0055"><b>new </b></font><font
color="#000000">ReflectiveItemProviderAdapterFactory</font ><font
color="#000000">())</font><font color="#000000">;</font></code> </td>
<!-- end source code --> </tr>
</tbody>
</table>
</div>
<!-- = END of automatically generated HTML code = -->
<!-- ======================================================== --><br>
<br>
<blockquote cite="mid:h3unuu$4vo$1@build.eclipse.org" type="cite">
<pre wrap="">And they must work on the same model i.e. on the
same file. It would be nice because than every gmf editor can have its
own graphical notations.
</pre>
</blockquote>
Generally EMF Transaction or the CDO Model Repository offer
transactionality and multi user characteristics, although they do it
quite differently. It could make sense to ask the GMF newsgroup for
more infos on how they do it.<br>
<br>
Cheers<br>
/Eike<br>
<br>
----<br>
<a class="moz-txt-link-freetext" href="http://thegordian.blogspot.com">http://thegordian.blogspot.com</a><br>
<a class="moz-txt-link-freetext" href="http://twitter.com/eikestepper">http://twitter.com/eikestepper</a><br>
<br>
<br>
</body>
</html>

--------------050406020805070104060507--


Re: first create classes then move them into package [message #431626 is a reply to message #431623] Sun, 19 July 2009 11:40 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: formatzeh.gmx.de

Thansk for your anser Eike,
I think I can arrange myself with the models-without-subpackages-issue.
Maybe I become a cool guy one day ;) But as I'm new on the EMF field,
modeling and so on I'll try learning from generating my editor for my
model. Therefore I want to investigate what properties can be made in
the genmodel. Is there a detailed overview of the possibilities of the
genmodel. I mean there are several options which can be made. I think I
need some explanations of those. Or a detailed tutorial would be nice.
Does anybody has some hints?
Re: first create classes then move them into package [message #431627 is a reply to message #431626] Sun, 19 July 2009 11:52 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6457
Registered: July 2009
Senior Member
Gilbert Mirenque schrieb:
> Thansk for your anser Eike,
> I think I can arrange myself with the models-without-subpackages-issue.
> Maybe I become a cool guy one day ;) But as I'm new on the EMF field,
> modeling and so on I'll try learning from generating my editor for my
> model. Therefore I want to investigate what properties can be made in
> the genmodel.
The status line always gives a short explanation of the selected property.

> Is there a detailed overview of the possibilities of the
> genmodel. I mean there are several options which can be made. I think I
> need some explanations of those. Or a detailed tutorial would be nice.
> Does anybody has some hints?
>
The book is definitely a must-have:
http://www.informit.com/store/product.aspx?isbn=978032133188 5

Cheers
/Eike

----
http://thegordian.blogspot.com
http://twitter.com/eikestepper


Re: first create classes then move them into package [message #431629 is a reply to message #431627] Sun, 19 July 2009 12:19 Go to previous message
Eclipse UserFriend
Originally posted by: formatzeh.gmx.de

Eike Stepper wrote:

> The status line always gives a short explanation of the selected property.
Oh thanks :) I haven't seen it yet.

> The book is definitely a must-have:
> http://www.informit.com/store/product.aspx?isbn=978032133188 5
Oh yes i heard of that book. I should consider to buy it as I see that
it is always lent in the library

best regards,
Gilbert
Previous Topic:[CDO] CDO sources and "Unsatisfied version constraint"
Next Topic:[CDO] Thread race condition with two transactions.
Goto Forum:
  


Current Time: Mon Dec 09 08:36:00 GMT 2019

Powered by FUDForum. Page generated in 0.01746 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top