| Re: Integrating EMF / GMF editors article - comments [message #173887] |
Sat, 23 February 2008 11:50  |
Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
Felix,
I'm sure Volker and Alex will appreciated the feedback. I've added the
GMF newsgroup to the "to" list of the reply so Alex is more likely to
see it.
Felix Mueller wrote:
> Hello!
>
> I tried integrating EMF and GMF editors using the very instructive
> article by Volker Wegert and Alex Shatalin (thanks a lot!) -
> http://www.eclipse.org/articles/article.php?file=Article-Int egrating-EMF-GMF-Editors/index.html
>
> The goal was to produce a RCP app with an EMF Editor and 2 GMF editors
> (1 main editor to be included in the MultiPageEditorPart and 1 adressed
> via Diagram Partitioning, shared EditingDomain). Diagrams are stored in
> the same file as the domain elements. The prototype was built using GMF
> 2.0.1 and EMF 2.3.1.
>
> While it is working now, I think the tutorial can be improved to make
> the process easier for dummies like me (if there are any; otherwise,
> please ignore :-) ).
>
> Here are my comments:
>
> 1. Checking the GMF plugins' org.eclipse.emf.ecore.extension_parser for
> the right file extension helps. Otherwise, havoc will emerge. While
> this requirement is already listed implicitly, it might be helpful to
> add this explicitly in /BIG BOLD RED LETTERS/.
>
> 2. RCP is easy. The GMF RCP editors use URIEditorInputs anyways, so you
> can use a very simple URIEditorInputProxy wrapper extending
> URIEditorInput with 1 additional field for the EditingDomain. It
> might be helpful and easy to include a subsection "RCP variant" in
> "Extending the Editor Input".
>
> 3. Register the EditingDomain in the EMF plugin. If you use 2 or more
> GMF plugins using a shared editing domain, you'd typically add the
> shared editing domain in one of these editors' plugin.xml. Instead,
> use the EMF editor's. This helps to get the Editor dirty; maybe
> someone could elaborate on that or provide an appropriate link to an
> article regarding notifications and the role of the EditingDomain's
> CommandStack...
>
> 4. In TopicmapEditor, retrieve the domain if it already exists:
>
> protected void initializeEditingDomain() {
> (...)
> TransactionalEditingDomain domain =
> TransactionalEditingDomain.Registry.INSTANCE.getEditingDomai n( "org.example.emfgmf.diagram.EditingDomain");
> if(domain==null) {
> domain = TransactionalEditingDomain.Factory.INSTANCE.createEditingDom ain();
> domain.setID("org.example.emfgmf.diagram.EditingDomain");
> }
>
> 5. Is there a more elegant way for integrating the PropertySheets?
>
> Again, thanks for this article! I hope, these comments are helpful for
> others starting to work with these frameworks.
>
> Bye Bye!
>
>
|
|
|
| Re: Integrating EMF / GMF editors article - comments [message #175179 is a reply to message #173887] |
Mon, 03 March 2008 17:17  |
 Alexander Shatalin
Messages: 2928
Registered: July 2009 |
Senior Member |
|
|
Hello Ed, Felix,
> I'm sure Volker and Alex will appreciated the feedback. I've added
Sure we are! ;-)
>> 1. Checking the GMF plugins' org.eclipse.emf.ecore.extension_parser
>> for the right file extension helps. Otherwise, havoc will emerge.
>> While this requirement is already listed implicitly, it might be
>> helpful to add this explicitly in /BIG BOLD RED LETTERS/.
Do you mean http://www.eclipse.org/articles/Article-Integrating-EMF-GMF- Editors/index.html#setting_the_stage,
point 7. ?
>> 2. RCP is easy. The GMF RCP editors use URIEditorInputs anyways, so
>> you
>> can use a very simple URIEditorInputProxy wrapper extending
>> URIEditorInput with 1 additional field for the EditingDomain. It
>> might be helpful and easy to include a subsection "RCP variant" in
>> "Extending the Editor Input".
Thanks for this suggestion - we should definitely mention this way to solve
the problem in RCP application section.
>> 3. Register the EditingDomain in the EMF plugin. If you use 2 or more
>> GMF plugins using a shared editing domain, you'd typically add the
>> shared editing domain in one of these editors' plugin.xml. Instead,
>> use the EMF editor's. This helps to get the Editor dirty; maybe
>> someone could elaborate on that or provide an appropriate link to an
>> article regarding notifications and the role of the EditingDomain's
>> CommandStack...
Well, you are right - it's not clear that corresponding part of "Sharing
single EditingDomain ..."
wiki page should be skipped to force GMF-generated editors using EditingDomain
instance passed in EditorInput.
I have to update "Sharing single EditingDomain ..." wiki page to better explain
the purpose of
EditingDomain registration in plugin.xml and post your note there.
I don’t think we should cover the topic of integration several GMF-generated
editors with the
same EMF-generated one in the article.
>> 4. In TopicmapEditor, retrieve the domain if it already exists:
I prefer to modify TopicmapEditor to explicitly create new EditingDomain
instance instead.
I do not think sharing same EditingDomain instance across ALL the multi-page
editor instances
is useful.
>> 5. Is there a more elegant way for integrating the PropertySheets?
Well, what’s wrong with the current one?
>> Again, thanks for this article! I hope, these comments are helpful
>> for others starting to work with these frameworks.
Thank you for your feedback!
-----------------
Alex Shatalin
|
|
|
| Re: Integrating EMF / GMF editors article - comments [message #175393 is a reply to message #175179] |
Tue, 04 March 2008 09:52 |
| Eclipse User |
|
|
|
Originally posted by: felix.mueller.snafu.de
Hello,
* Alex Shatalin -- [2008-03-03] writes:
>>> 1. Checking the GMF plugins' org.eclipse.emf.ecore.extension_parser
>>> for the right file extension helps. Otherwise, havoc will emerge.
>>> While this requirement is already listed implicitly, it might be
>>> helpful to add this explicitly in /BIG BOLD RED LETTERS/.
> Do you mean
> http://www.eclipse.org/articles/Article-Integrating-EMF-GMF- Editors/index.html#setting_the_stage,
> point 7. ?
Exactly. It might be useful to add a reference to the extension point,
so checking this after code generation is easier ("If anything goes
wrong and your XXXDocumentProvider/ResourceSetModificationListener doesn't
receive notifications about changed Resources, check this!" :-) )
>>> 5. Is there a more elegant way for integrating the PropertySheets?
> Well, what’s wrong with the current one?
It is desireable to limit changes to the EMF/multipage editor to avoid
"two-way dependencies", IMHO. This is not very important, though (domain
model should not change that often) and might be different, if next-gen
EMF editors provide tabbed properties.
Bye!
--
Felix Müller
|
|
|
|
Powered by
FUDForum. Page generated in 0.02673 seconds
] 
Search
Help
Register
Login
Home
