Hy tom, yes exactly! I did not find a way to store my data within the application model itself! I tried approaches like EMF Facet, but they are not suitable to adding attributes to existing EClasses. So I have to store the data in a separate model, that refers to elements in the main application model!
cheers An 03. Februar 2014 at 18:11:01, Tom Schindl ([email protected]) schrieb: > > I don't get why you need to take part at the model saving. Do you > store > your information next to the model and not part of it? > > Tom > > On 03.02.14 17:48, Marco Descher wrote: > > Hy Wim, > > > > thanks for your feedback! Yes, I think its better, the problem > generally boils down to one question: > > > > I need to be informed at the EP about save() happening for the > main resource, so that I can store > > mine. The cheapest solution would surely be a saveHook EP so > anyone that might have this request is > > informed of this save event. > > > > I could as well just leave this problem out for the moment being > and care or the save on my site (by > > adding a save button to my contributed tabs for example). > > > > I’m really puzzled at the moment, but I don’t have a problem if > we hold on! > > > > atb, > > marco > > > > An 03. Februar 2014 at 17:41:52, Wim Jongman ([email protected]) > schrieb: > >> > >> It is hard to tell Marco. I have to make some time to really get > to > >> know > >> your solution. Do you think we should hold on to accepting your > >> patch until > >> this is sorted out? > >> > >> Cheers, > >> > >> Wim > >> > >> > >> > >> On Mon, Feb 3, 2014 at 4:10 PM, Marco Descher > >> wrote: > >> > >>> https://git.eclipse.org/r/#/c/18813/ > >>> > >>> I found a "minimally invasive" solution, which I do not really > >> like, so I > >>> hope for a better proposal: > >>> > >>> I extended my classes in general by giving them dependency > injection, > >> and > >>> if one extends the MApplication.class > >>> and has a method with @Persist in it, it gets called by the "parent" > >> so > >>> one can handle oneselves persistence. > >>> > >>> ==== ModelEditor:line 1366 > >>> @Persist > >>> public void doSave(@Optional IProgressMonitor monitor) > >> { > >>> > >>> try { > >>> setSaving(true); > >>> if (modelProvider.isSaveable()) { > >>> modelProvider.save(); > >>> > >>> List aeec = > >>> getTabContributionsForClass(MApplication.class); > >>> for (AbstractElementEditorContribution aeecChild : > >>> aeec) { > >>> try { > >>> ContextInjectionFactory.invoke(aeecChild, > >>> Persist.class, context); > >>> } catch (InjectionException e) { > >>> // ignore > >>> } > >>> } > >>> > >>> } > >>> } finally { > >>> setSaving(false); > >>> } > >>> } > >>> > >>> -- > >>> Marco Descher > >>> Sent with Airmail > >>> > >>> An 02. Februar 2014 at 22:49:47, Marco Descher ([email protected]) > >> schrieb: > >>>> > >>>> The extension itself works quite good for me you may have > a look > >>>> at it in https://git.eclipse.org/r/#/c/18813/ > >>>> > >>>> I am having a "problem" however, where I would like to see > your > >>>> comment: > >>>> > >>>> I use the extension point to load a second model, which connects > >>>> to the first model. Now I want to save the second > >>>> model when I do the save operation on the first model. The > respective > >>>> call is embedded in @Persist ModelEditor#doSave. > >>>> Now I cant seem to use DI in my contribution tabs, so I guess > I > >> would > >>>> have to pass the save method calling to the > >>>> extension point. As one may register several editorTab > contributions > >>>> (each e.g. for a specific element) I plan to extend another > >>>> class in the editorTab EP where this is passed to! > >>>> > >>>> Do you see a better solution for this I miss out? > >>>> > >>>> thanks, > >>>> marco > >>>> > >>>> An 17. Jänner 2014 at 16:07:23, Marco Descher ([email protected]) > >>>> schrieb: > >>>>> > >>>>> Hy Wim, > >>>>> > >>>>> ok, I agree. But I want to find a way to non-invasively extend > >>>> the > >>>>> existing application model first, as I think that then > the > >> extension > >>>>> point really makes sense! Currently I found EMF Facets > which > >>>>> could be a good starting point. And if it proves well, I would > >>>> create > >>>>> it the way, that facets are supported. Because this way > you > >> could > >>>>> provide your own facet with your own additional attributes > >>>> etc. > >>>>> and integrate them fully into the eclipse tooling. > >>>>> > >>>>> I will come up with the respective gerrit entries in due > time > >>>> :) > >>>>> > >>>>> thanks, > >>>>> marco > >>>>> > >>>>> -- > >>>>> Marco Descher > >>>>> Sent with Airmail > >>>>> > >>>>> An 17. Jänner 2014 at 16:02:58, Wim Jongman ([email protected]) > >>>>> schrieb: > >>>>>> > >>>>>> Hi Marco, > >>>>>> > >>>>>> Since there is no documentation attached to the existing > >> extension > >>>>>> point I > >>>>>> figured we can just use it the way we want. > >>>>>> > >>>>>> Take for example the ui.views extension point. It can > be > >> used > >>>>>> to add views > >>>>>> but also to add view categories. Two related but different > >>>> concepts. > >>>>>> Since > >>>>>> your extension works with the model editor it makes sense > >> to > >>>>> move > >>>>>> it to the > >>>>>> existing extension point. > >>>>>> > >>>>>> Regards, > >>>>>> > >>>>>> Wim > >>>>>> > >>>>>> > >>>>>> On Fri, Jan 17, 2014 at 1:17 PM, Marco Descher > >>>>>> wrote: > >>>>>> > >>>>>>> Hy Wim, > >>>>>>> > >>>>>>> as I found out during the documentation, the current > extension > >>>>>> point is > >>>>>>> not extending the tooling in this way. It is mainly focused > >>>>> on > >>>>>> adding > >>>>>>> editors for new model elements instead of augmenting > the > >>>> editor > >>>>>>> capabilities for existing elements (there are Exceptions > >>>>>> but I don't think > >>>>>>> they go the right way). I currently forked the tooling > on > >> github > >>>>>> and work > >>>>>>> with my own build (https://github.com/ecrit/e4.tools). > >>>>>> During this I > >>>>>>> might uncover some problems and do a complete refactoring. > >>>>>> So I think I > >>>>>>> just stick it this way at the moment, and will come up with > >> another > >>>>>>> integration approach in a few months! > >>>>>>> > >>>>>>> I also don't think that it makes much sense to augment > the > >> editing > >>>>>>> capabilites of the existing model elements, as most > certainly > >>>>>> you have to > >>>>>>> add new attributes to these, or did I miss a way to contribute > >>>>>> to existing > >>>>>>> elements, without having to create new EMF classes extending > >>>>>> those? > >>>>>>> > >>>>>>> thanks, > >>>>>>> marco > >>>>>>> > >>>>>>> An 07. Jänner 2014 at 10:46:09, Marco Descher ([email protected]) > >>>>>> schrieb: > >>>>>>>> > >>>>>>>> Hy there, > >>>>>>>> > >>>>>>>> that would make sense, I guess. Although I think that > I > >> would > >>>>>> first > >>>>>>>> have to document the existing extension point > >>>>>>>> code some more to be sure about it. I'll open a bug for > adding > >>>>>> some > >>>>>>>> documentation and throw it on gerrit then. > >>>>>>>> > >>>>>>>> cheers, > >>>>>>>> marco > >>>>>>>> > >>>>>>>> An 06. Jänner 2014 at 18:23:47, Wim Jongman ( > >>> [email protected]) > >>>>>>>> schrieb: > >>>>>>>>> > >>>>>>>>> Marco how would you feel moving your extension to the > >> already > >>>>>>>>> existing > >>>>>>>>> extension point. > >>>>>>>>> > >>>>>>>>>> point="org.eclipse.e4.tools.emf.ui.editors"> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Tom would this be the right point to extend the model > editor? > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> On Tue, Nov 26, 2013 at 11:12 AM, Sopot Çela > >>>>>>>>> wrote: > >>>>>>>>> > >>>>>>>>>> Thanks Marco, I'll take a look and get back to you. > >>>>>>>>>> > >>>>>>>>>> Sopot > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> On Mon, Nov 25, 2013 at 12:57 PM, Marco Descher > >>>>>>>>> wrote: > >>>>>>>>>> > >>>>>>>>>>> Hy Sopot, > >>>>>>>>>>> > >>>>>>>>>>> I created a short demo, and pushed it to gerrit in > >>>>>>>>>>> https://git.eclipse.org/r/#/c/18813/ . A sample > >>>> plug-in > >>>>>>>>> consuming the > >>>>>>>>>>> respective extension point is available on > >>>>>>>>>>> > >>>>>>> > >>> https://github.com/col-panic/generic-stuff/commit/cb4cc272ab4d0da33cd7462519c0ed51231fc029 > >>> > >>>>>>> . > >>>>>>>>>>> > >>>>>>>>>>> It is intentionally kept simple, and hacked!! So > for > >>>> an > >>>>>> element > >>>>>>>>> of type > >>>>>>>>>>> MPart you get an additional CTabItem where currently > >>>>> simply > >>>>>>>>> the ID > >>>>>>>>>>> attribute is mirrored. > >>>>>>>>>>> > >>>>>>>>>>> It should show the basic concept and point out the > required > >>>>>>>>> refactorings?! > >>>>>>>>>>> > >>>>>>>>>>> cheers, > >>>>>>>>>>> marco > >>>>>>>>>>> > >>>>>>>>>>> Am 20.11.2013 um 09:59 schrieb Sopot Çela : > >>>>>>>>>>> > >>>>>>>>>>> Marco would you be able to make a proof of concept > for > >> one > >>>>>> element > >>>>>>>>> (say > >>>>>>>>>>> MPart) and throw it on gerrit? I like the idea in principle > >>>>>>>> but > >>>>>>>>> it would be > >>>>>>>>>>> great to have something to see and extend and get > the > >> feel > >>>>>> of > >>>>>>>>> it from my > >>>>>>>>>>> keyboard. > >>>>>>>>>>> > >>>>>>>>>>> Sopot > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> On Wed, Nov 20, 2013 at 8:08 AM, Lars Vogel > >>>>>>>>> wrote: > >>>>>>>>>>> > >>>>>>>>>>>> Hi, > >>>>>>>>>>>> > >>>>>>>>>>>> I think we should avoid a dependency to ECP. > >>>>>>>>>>>> > >>>>>>>>>>>> At some point the tooling should migrate to PDE > or > >> platform > >>>>>>>>> and these > >>>>>>>>>>>> tools can AFAIK not depend on a higher level in Eclipse. > >>>>>>>>>>>> > >>>>>>>>>>>> Best regards, Lars > >>>>>>>>>>>> Am 19.11.2013 21:25 schrieb "Jonas Helming" < > >>>>>>>>>>>> [email protected]>: > >>>>>>>>>>>> > >>>>>>>>>>>> Hi, > >>>>>>>>>>>>> I totally like the idea. However, it reminds me > to > >> an > >>>>> idea > >>>>>>>>> I have since > >>>>>>>>>>>>> a long time, which is related to your question. > >>>>>>>>>>>>> When Tom implemented the first version of the > e4 > >> tools > >>>>>> editor, > >>>>>>>>> he > >>>>>>>>>>>>> actually contacted me if the EMF Client Platform > >> could > >>>>>>>> be > >>>>>>>>> used for this. > >>>>>>>>>>>>> Back than, ECP had some restrictions: > >>>>>>>>>>>>> > >>>>>>>>>>>>> 1. The form-based editor was not really usable > stand-alone > >>>>>>>>> or embeddable > >>>>>>>>>>>>> 2. We did not really support to customize the layout > >>>>>>>>>>>>> 3. We did not support a Master Detail view within > >> a form > >>>>>>>>>>>>> > >>>>>>>>>>>>> In the mean time, these restrictions are not valid > >>>> anymore: > >>>>>>>>>>>>> 1. The editor component can be used stand-alone > >> and > >>>>> embedded > >>>>>>>>> everywere, > >>>>>>>>>>>>> it is a sub component called EMF Forms > >>>>>>>>>>>>> 2. The layout of the form-based UI can itself be > described > >>>>>>>>> with an EMF > >>>>>>>>>>>>> model (see > >>>>>>>>>>>>> > >>>>>>> > >>> http://eclipsesource.com/blogs/tutorials/emf-client-platform-how-to-customize-the-editor-layout/ > >>> > >>>>>>>>>>>>> ) > >>>>>>>>>>>>> 3. We currently develop a master detail view, > which > >>>>> is > >>>>>> almost > >>>>>>>>> finished > >>>>>>>>>>>>> > >>>>>>>>>>>>> Major advantages of this would be IMHO: > >>>>>>>>>>>>> 1. The code base of the e4 editor would get drastically > >>>>>> smaller > >>>>>>>>> and > >>>>>>>>>>>>> would only focus on e4 model specific aspects > >>>>>>>>>>>>> 2. Custom Applications elements can be edited > without > >>>>>>>> any > >>>>>>>>> adaption, as > >>>>>>>>>>>>> ECP still support reflective UIs > >>>>>>>>>>>>> 3. The layout of the editor can be easily customized > >>>>> by > >>>>>> users > >>>>>>>>> using a > >>>>>>>>>>>>> view model > >>>>>>>>>>>>> 4. New concepts such as the one you describe can > be > >> asily > >>>>>>>> added > >>>>>>>>>>>>> 5. The e4 editor would benefit from ECP features, > >> e.g. > >>>>>> validation > >>>>>>>>>>>>> > >>>>>>>>>>>>> The main disadvantage is of course that this would > >>>> require > >>>>>>>>> initial > >>>>>>>>>>>>> effort. Your suggested solution is of course > much > >>>> easier > >>>>>>>>> to implement for > >>>>>>>>>>>>> now. Additionally e4 Tools would get a depenency > >> to > >>>>> ECP. > >>>>>>>>>>>>> > >>>>>>>>>>>>> I just wanted to share this thought to get peoples > >>> opinions. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Cheers > >>>>>>>>>>>>> > >>>>>>>>>>>>> Jonas > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> Am 19.11.2013 13:05, schrieb Marco Descher: > >>>>>>>>>>>>> > >>>>>>>>>>>>> Hy List, > >>>>>>>>>>>>> > >>>>>>>>>>>>> WHAT > >>>>>>>>>>>>> > >>>>>>>>>>>>> I would like to add horizontal extension possibility > >>>>>> to > >>>>>>>>> the e4 > >>>>>>>>>>>>> tooling. That is, there already is the possibility > >>>>> to > >>>>>> add > >>>>>>>>> new elements to > >>>>>>>>>>>>> the application model, and provide ones own editors > >>>>>>>>>>>>> for the e4 tooling. I would like to extend the tooling > >>>>>> for > >>>>>>>>> already > >>>>>>>>>>>>> available elements by adding an extension point > >> to > >>>>> the > >>>>>>>> tooling > >>>>>>>>> itself. > >>>>>>>>>>>>> > >>>>>>>>>>>>> WHY > >>>>>>>>>>>>> > >>>>>>>>>>>>> I want to enrich already available elements with > >>> additional > >>>>>>>>>>>>> information. This could for example be used to > add > >>>> documentation > >>>>>>>>>>>>> information to all elements of the application > >> model, > >>>>>>>>>>>>> or would allow me to e.g. create an additional > tab, > >>>> valid > >>>>>>>>> only if I use > >>>>>>>>>>>>> the SWT renderer, allowing me to do deeper inspection > >>>>>> of > >>>>>>>>> the model. > >>>>>>>>>>>>> > >>>>>>>>>>>>> HOW > >>>>>>>>>>>>> > >>>>>>>>>>>>> I plan to create an extension point allowing to > contribute > >>>>>>>>> tabs to > >>>>>>>>>>>>> given elements, as can be seen in the following > image. > >>>>>> The > >>>>>>>>> extension point > >>>>>>>>>>>>> will have to define for > >>>>>>>>>>>>> what model elements the contributed tab is valid, > >>>> and > >>>>>> on > >>>>>>>>> call of the > >>>>>>>>>>>>> editor the full model will be passed. > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> Can you please give me any feedback, on what you > think > >>>>>> about > >>>>>>>>> this, > >>>>>>>>>>>>> who would back/mentor this implementation, > and > >> what > >>>>>> he/she > >>>>>>>>> would do > >>>>>>>>>>>>> different? > >>>>>>>>>>>>> > >>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>> marco > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> _______________________________________________ > >>>>>>>>>>>>> e4-dev mailing [email protected]:// > >>>>>>> dev.eclipse.org/mailman/listinfo/e4-dev > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> _______________________________________________ > >>>>>>>>>>>>> e4-dev mailing list > >>>>>>>>>>>>> [email protected] > >>>>>>>>>>>>> https://dev.eclipse.org/mailman/listinfo/e4-dev > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>> _______________________________________________ > >>>>>>>>>>>> e4-dev mailing list > >>>>>>>>>>>> [email protected] > >>>>>>>>>>>> https://dev.eclipse.org/mailman/listinfo/e4-dev > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>> _______________________________________________ > >>>>>>>>>>> e4-dev mailing list > >>>>>>>>>>> [email protected] > >>>>>>>>>>> https://dev.eclipse.org/mailman/listinfo/e4-dev > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> _______________________________________________ > >>>>>>>>>>> e4-dev mailing list > >>>>>>>>>>> [email protected] > >>>>>>>>>>> https://dev.eclipse.org/mailman/listinfo/e4-dev > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> _______________________________________________ > >>>>>>>>>> e4-dev mailing list > >>>>>>>>>> [email protected] > >>>>>>>>>> https://dev.eclipse.org/mailman/listinfo/e4-dev > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> _______________________________________________ > >>>>>>>>> e4-dev mailing list > >>>>>>>>> [email protected] > >>>>>>>>> https://dev.eclipse.org/mailman/listinfo/e4-dev > >>>>>>>>> > >>>>>>>> > >>>>>>>> _______________________________________________ > >>>>>>>> e4-dev mailing list > >>>>>>>> [email protected] > >>>>>>>> https://dev.eclipse.org/mailman/listinfo/e4-dev > >>>>>>>> > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> e4-dev mailing list > >>>>>>> [email protected] > >>>>>>> https://dev.eclipse.org/mailman/listinfo/e4-dev > >>>>>>> > >>>>>> _______________________________________________ > >>>>>> e4-dev mailing list > >>>>>> [email protected] > >>>>>> https://dev.eclipse.org/mailman/listinfo/e4-dev > >>>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> e4-dev mailing list > >>>>> [email protected] > >>>>> https://dev.eclipse.org/mailman/listinfo/e4-dev > >>>>> > >>>> > >>>> _______________________________________________ > >>>> e4-dev mailing list > >>>> [email protected] > >>>> https://dev.eclipse.org/mailman/listinfo/e4-dev > >>>> > >>> > >>> _______________________________________________ > >>> e4-dev mailing list > >>> [email protected] > >>> https://dev.eclipse.org/mailman/listinfo/e4-dev > >>> > >> _______________________________________________ > >> e4-dev mailing list > >> [email protected] > >> https://dev.eclipse.org/mailman/listinfo/e4-dev > >> > > > > _______________________________________________ > > e4-dev mailing list > > [email protected] > > https://dev.eclipse.org/mailman/listinfo/e4-dev > > > > _______________________________________________ > e4-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/e4-dev > _______________________________________________ e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/e4-dev
