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 (wim.jong...@gmail.com) 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 (ma...@descher.at) >> 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 (ma...@descher.at) >>>> 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 (wim.jong...@gmail.com) >>>>> 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 (ma...@descher.at) >>>>>> 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 ( >>> wim.jong...@gmail.com) >>>>>>>> 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" < >>>>>>>>>>>> jonas.helm...@googlemail.com>: >>>>>>>>>>>> >>>>>>>>>>>> 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 liste4-dev@eclipse.orghttps:// >>>>>>> dev.eclipse.org/mailman/listinfo/e4-dev >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> e4-dev mailing list >>>>>>>>>>>>> e4-dev@eclipse.org >>>>>>>>>>>>> https://dev.eclipse.org/mailman/listinfo/e4-dev >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> e4-dev mailing list >>>>>>>>>>>> e4-dev@eclipse.org >>>>>>>>>>>> https://dev.eclipse.org/mailman/listinfo/e4-dev >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> e4-dev mailing list >>>>>>>>>>> e4-dev@eclipse.org >>>>>>>>>>> https://dev.eclipse.org/mailman/listinfo/e4-dev >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> e4-dev mailing list >>>>>>>>>>> e4-dev@eclipse.org >>>>>>>>>>> https://dev.eclipse.org/mailman/listinfo/e4-dev >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> e4-dev mailing list >>>>>>>>>> e4-dev@eclipse.org >>>>>>>>>> https://dev.eclipse.org/mailman/listinfo/e4-dev >>>>>>>>>> >>>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> e4-dev mailing list >>>>>>>>> e4-dev@eclipse.org >>>>>>>>> https://dev.eclipse.org/mailman/listinfo/e4-dev >>>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> e4-dev mailing list >>>>>>>> e4-dev@eclipse.org >>>>>>>> https://dev.eclipse.org/mailman/listinfo/e4-dev >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> e4-dev mailing list >>>>>>> e4-dev@eclipse.org >>>>>>> https://dev.eclipse.org/mailman/listinfo/e4-dev >>>>>>> >>>>>> _______________________________________________ >>>>>> e4-dev mailing list >>>>>> e4-dev@eclipse.org >>>>>> https://dev.eclipse.org/mailman/listinfo/e4-dev >>>>>> >>>>> >>>>> _______________________________________________ >>>>> e4-dev mailing list >>>>> e4-dev@eclipse.org >>>>> https://dev.eclipse.org/mailman/listinfo/e4-dev >>>>> >>>> >>>> _______________________________________________ >>>> e4-dev mailing list >>>> e4-dev@eclipse.org >>>> https://dev.eclipse.org/mailman/listinfo/e4-dev >>>> >>> >>> _______________________________________________ >>> e4-dev mailing list >>> e4-dev@eclipse.org >>> https://dev.eclipse.org/mailman/listinfo/e4-dev >>> >> _______________________________________________ >> e4-dev mailing list >> e4-dev@eclipse.org >> https://dev.eclipse.org/mailman/listinfo/e4-dev >> > > _______________________________________________ > e4-dev mailing list > e4-dev@eclipse.org > https://dev.eclipse.org/mailman/listinfo/e4-dev > _______________________________________________ e4-dev mailing list e4-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/e4-dev