Home » Eclipse Projects » GEF » EMF+GEF integration documentation/examples/redbook
| EMF+GEF integration documentation/examples/redbook [message #88400] |
Fri, 25 July 2003 05:37  |
Eclipse User |
|
|
|
Cross Post: from eclipse.tools.emf.
Dear EMF Folks,
I am building a plugin which I plan to base on the EMF generated editor
of a model built from java interfaces. I want a GEF editor with palette
to work on subparts of the model.
I have been browsing almost all available documentation (news groups,
articles, cvs, wiki, ...) and I have not found much help in how to
build an editor using EMF and GEF. Do you have any references to good
examples/articles you want to share?
I have read that august 15th an IBM redbook on the subject should appear
(or at least that is when the residency should stop). Does anyone
have/want to share more information, e.g. are there any drafts available
or something?
Thanks for a very nice "product"
/\/ikolaj
|
|
| | | | | |
| Re: EMF+GEF integration documentation/examples/redbook [message #89278 is a reply to message #89248] |
Wed, 30 July 2003 11:29  |
| Eclipse User |
|
|
|
Dear Groups,
Please don't read the following as an attempt to "troll". I am merely
trying to find out if my own poor understanding of GEF and EMF is good
enough, and whether the path I am going to choose for my application the
"best".
Randy Hudson wrote:
>> Where are the actual dependencies on emf's Command and CommandStack? AFAIK,
>> the only plugins which require them are part of EMF Edit, not EMF (pure
>> modeling) itself. If you generate an EMF model, I don't think it will have
>> any dependencies on EMF's Command framework.
I cannot confirm your understanding of EMF's commands since I am no
expert (will be eventually, hopefully :-). Maybe the cross post here can
provide an answer/confirmation.
If I get your drift, however, you are saying :- use EMF to generate
model and leave the .edit and .editor projects alone, then use GEF
framework for the viewer and controllers (editors). At least that is in
sync with what you have previously said in the NGs (the way I read it).
I am inclined, though, to want to base my project (which is still in an
early phase) on the the EMF generated .editor (thus needing all the EMF
generated code) for the following reasons:
1) EMF gives me commands to add, delete etc. model objects. With GEF I
have to write them manually (appears easy, but I still prefer to get
them generated)
2) I like the SelectionViewer and the PropertiesViewer that EMF
generates for me. I want to have a GEF editor for appropriate selected
parts of the model (think a slide show - with the Selection Viewer I
select a slide which I can then edit in a GEF editor).
3) I can freely use the EMF generated code under my own license.
4) Since the Logic Editor comes CPL'ed I would have to start from
scratch writing a graphical editor if I do not want to CPL my own code.
Since I cannot use a cut-down version of the code as the base for an
application, I will not save anything by going with the GEF commands,
etc. framework, rather than going with the EMF one. There is even a
Command wrapper between GEF and EMF in the NG (which I can link against
if I understand the CPL correctly - it is a bit like the LGPL?)
I am happy to be corrected/persuaded on the above arguments. Better now
than later ;-)
As an argument against it I would need more wrapper code, but that is
reusable code and appears to be not too difficult to make.
Btw. In my attempts to integrate a GEF editor into EMF generated code I
wanted to insert a GraphicalEditorWithPalette in a tab in the
MultipageEditor. After some attempts I succeeded by performing the the
following steps:
class Foo extends MultiPageEditor {
// ...
createPages() {
// ...
NBEditor ke = new NBEditor();
try {
int index = addPage(ke, ke.getEditorInput());
setPageText(index, "place Holder for GEF editor");
} catch (PartInitException e) {
e.printStackTrace();
}
// ...
}
NBEditor is just a subclasssing of GraphicalEditor providing dummy
implementations of the abstract methods with the single exception of:
import org.eclipse.gef.DefaultEditDomain;
import org.eclipse.gef.ui.parts.GraphicalEditor;
public class NBEditor extends GraphicalEditor {
NBEditor() {
setEditDomain(new DefaultEditDomain(this));
}
// ...
}
Presently I don't know whether I should be using GEF or EMF EditDomain
for my approach, suggestions?
I was not able to find hints for producing the above code anywhere, so
here goes my little contribution to any one else who want to do EMF+GEF
without knowing much about eclipse and jface.
By the way I would like to vote for integration of the EMF and GEF
frameworks (as has been suggested earlier) - collaps commands,
editdomains, commandstack, ... As an argument for it: I think most
people would like exactly the functionality they can get from EMF+GEF: a
graphical editor with XML save/restore. If people do not like XML as
serialisation format they can replace the XML functionality with their
own - EMF is prepared for it. If the integration can be made in a way
that leaves open the choice of model (which is a strong feature of GEF
for people with a lot of legacy code) then I don't see any arguments
against it. But then again, I am no expert on either.
Regards,
/\/ikolaj
>
> "Richard L. Kulp" <richkulp@NOSPAM.us.ibm.com> wrote in message
> news:bg6tr1$d42$1@eclipse.org...
>
>>One caveat, EMF and GEF use different command stacks and Command
>>interfaces. They can't be used together (i.e. an EMF command can't be
>>put onto GEF command stack and visa-versa). You will need a wrapper that
>>can make one look the other depending upon which command stack you are
>>using.
>>
>>Rich
>>
>
>
>
|
|
|
| Re: EMF+GEF integration documentation/examples/redbook [message #89323 is a reply to message #89278] |
Wed, 30 July 2003 13:51 |
| Eclipse User |
|
|
|
Originally posted by: none.us.ibm.com
> If I get your drift, however, you are saying :- use EMF to generate
> model and leave the .edit and .editor projects alone, then use GEF
Based on what I've heard, this is the easiest and quickest approach. The
..edit project is useful for basic models and editors. It has limitation.
For example, you cannot show a treeitem unless there is something in the
model that corresponds to it. So, to make the GEF analogy, you have a
connection between two nodes and you want to display the connection's name
as an editable label.
> framework for the viewer and controllers (editors). At least that is in
> sync with what you have previously said in the NGs (the way I read it).
>
> I am inclined, though, to want to base my project (which is still in an
> early phase) on the the EMF generated .editor (thus needing all the EMF
> generated code) for the following reasons:
> 1) EMF gives me commands to add, delete etc. model objects. With GEF I
> have to write them manually (appears easy, but I still prefer to get
> them generated)
For many applications, adding something is more complex and default commands
are of no use. For example, creating a UML Class requires:
1) Creating a Class object
2) Creating a ClassView object
3) Set the ClassView's "Class" reference
4) Creating an XY constraint object and setting it on the ClassView
5) Adding the ClassView to the Diagram
6) Adding the Class to a namespace.
If you are adding an existing class to a diagram, you must:
1) Create a ClassView object
2) Set the ClassView's class reference
2) Create an XY constraint object and set it on the ClassView
3) Add the ClassView to the Diagram
4) Identifying the set of relationship which can now be viewed because of
the added classview, and create and add RElationshipViews for reach
relationship
Using EMF Edit, how would you know the difference between adding a new class
vs. adding a class which already existed in the namespace? The undo is
different for each scenario.
> 4) Since the Logic Editor comes CPL'ed I would have to start from
> scratch writing a graphical editor if I do not want to CPL my own code.
> Since I cannot use a cut-down version of the code as the base for an
> application, I will not save anything by going with the GEF commands,
The commands in the Logic example are specific to the logic example's model.
I'm not sure what you would copy, but feel free to copy anything you want.
> Presently I don't know whether I should be using GEF or EMF EditDomain
> for my approach, suggestions?
GEF's EditDomain is not related to EMF's EditDomain. They are used for two
completely different things.
|
|
|
| Re: EMF+GEF integration documentation/examples/redbook [message #89399 is a reply to message #89323] |
Wed, 30 July 2003 09:03 |
| Eclipse User |
|
|
|
Randy Hudson wrote:
>>If I get your drift, however, you are saying :- use EMF to generate
>>model and leave the .edit and .editor projects alone, then use GEF
> Based on what I've heard, this is the easiest and quickest approach. The
> .edit project is useful for basic models and editors. It has limitation.
> For example, you cannot show a treeitem unless there is something in the
> model that corresponds to it. So, to make the GEF analogy, you have a
> connection between two nodes and you want to display the connection's name
> as an editable label.
> For many applications, adding something is more complex and default commands
> are of no use. For example, creating a UML Class requires:
I hear what you say. I will re-consider the proper choice of commands
pertaining to my specific model/give it a reality check.
>>4) Since the Logic Editor comes CPL'ed I would have to start from
>>scratch writing a graphical editor if I do not want to CPL my own code.
>>Since I cannot use a cut-down version of the code as the base for an
>>application, I will not save anything by going with the GEF commands,
> The commands in the Logic example are specific to the logic example's model.
> I'm not sure what you would copy, but feel free to copy anything you want.
I meant GEF command framework. I would keep my commands in the .edit
domain and just wrap through to it. But again, this will get reconsidered.
When you say "feel free to copy anything you want" do you mean that one,
in principle, could cut down the logic editor to some skeleton app and
start development from there? Without having to relase under the CPL? Or
am I applying the phrase out of context (really just applying to the
logic-model related commands)?
If so, why is the example CPL'ed and not in the public domain?
I am asking because the License on the Logic editor puzzles me. Is it a
deliberate choice because IBM hopes to sell non-CPL'ed versions of the
Logic Editor codebase (like the business plan of TrollTechs QT library,
and Mysql's mysql). Or is it rather, everything that goes in the
direction of Eclipse is CPL'ed in an automated way?
Likewise I noted that the wizard for the multipage editor generates
CPL'ed code. This might be a question outside the scope of this group,
but perhaps you are in a position to answer to some degree?
> GEF's EditDomain is not related to EMF's EditDomain. They are used for two
> completely different things.
I will read up on it, just noticed the name collapse when doing a quick
comparison/overview on SWT,jface,eclipse,emf,gef.
Thanks for your time!
/\/ikolaj
|
|
|
| Re: EMF+GEF integration documentation/examples/redbook [message #89499 is a reply to message #89137] |
Thu, 31 July 2003 09:11 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
Colin,
As far as I know, there is no technical reason why GEF cannot simply use (and
extend) EMF's command framework; it certainly did exactly that in the past. We've
explored generating GEF-based views in the generated editor a few times already,
but other priorities and resource constraints have always prevented us from
completing the task. It would be really cool for both EMF and GEF to be able to
generate a simple working graphical editing application...
Colin Sharples wrote:
> Randy Hudson wrote:
> > There's not much to combining these two technologies. EMF provides a model
> > and persistence. GEF allows you to use any model you want. There is a new
> > article on getting started with GEF, which talks about the model
> > requirements
>
> How much work do you think it would be to get EMF to generate a default
> GEF based editor? Anything that you can edit with a tree editor you
> could represent in a UML-like diagram with boxes for elements and
> connections for parent-child relationships.
>
> --
> Colin M Sharples/New Zealand/IBM, IT Architect, IBM Global Services
> sharples@nz.ibm.com, t: 64-4-5769853, m: 64-21-402085, f: 64-4-5765616
> "Sometimes I think the surest sign intelligent life exists
> elsewhere in the Universe is that it's never tried to contact us"
|
|
|
| Re: EMF+GEF integration documentation/examples/redbook [message #89545 is a reply to message #89499] |
Thu, 31 July 2003 19:05 |
| Eclipse User |
|
|
|
Ed Merks wrote:
> As far as I know, there is no technical reason why GEF cannot simply use (and
> extend) EMF's command framework; it certainly did exactly that in the past. We've
> explored generating GEF-based views in the generated editor a few times already,
> but other priorities and resource constraints have always prevented us from
> completing the task. It would be really cool for both EMF and GEF to be able to
> generate a simple working graphical editing application...
I'd be delighted to help - after the middle of September when the
project I'm on finishes :-)
--
Colin M Sharples/New Zealand/IBM, IT Architect, IBM Global Services
sharples@nz.ibm.com, t: 64-4-5769853, m: 64-21-402085, f: 64-4-5765616
"Sometimes I think the surest sign intelligent life exists
elsewhere in the Universe is that it's never tried to contact us"
|
|
|
Goto Forum:
Current Time: Sun May 11 04:11:36 EDT 2025
Powered by FUDForum. Page generated in 0.04984 seconds |
Home