Hm - ok I see so the best solution would if we'd have a slot in the application model which takes an EObject. I doubt we can get something like this in into the model at this point of the lifecycle, we need something like
EMap<String,EObject> metaData Tom On 03.02.14 19:17, Marco Descher wrote: > 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 > _______________________________________________ e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/e4-dev
