Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [e4-dev] Horizontal extension possibility for e4 tooling

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.jongman@xxxxxxxxx) 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 (marco@xxxxxxxxxx)  
>> 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 (marco@xxxxxxxxxx)  
>>>> 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.jongman@xxxxxxxxx)  
>>>>> 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 (marco@xxxxxxxxxx)  
>>>>>> 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.jongman@xxxxxxxxx)
>>>>>>>> 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.helming@xxxxxxxxxxxxxx>:
>>>>>>>>>>>>
>>>>>>>>>>>> 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@xxxxxxxxxxx
>>>>>>>>>>>>> https://dev.eclipse.org/mailman/listinfo/e4-dev  
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________  
>>>>>>>>>>>> e4-dev mailing list
>>>>>>>>>>>> e4-dev@xxxxxxxxxxx
>>>>>>>>>>>> https://dev.eclipse.org/mailman/listinfo/e4-dev  
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________  
>>>>>>>>>>> e4-dev mailing list
>>>>>>>>>>> e4-dev@xxxxxxxxxxx
>>>>>>>>>>> https://dev.eclipse.org/mailman/listinfo/e4-dev  
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________  
>>>>>>>>>>> e4-dev mailing list
>>>>>>>>>>> e4-dev@xxxxxxxxxxx
>>>>>>>>>>> https://dev.eclipse.org/mailman/listinfo/e4-dev  
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________  
>>>>>>>>>> e4-dev mailing list
>>>>>>>>>> e4-dev@xxxxxxxxxxx
>>>>>>>>>> https://dev.eclipse.org/mailman/listinfo/e4-dev  
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> _______________________________________________  
>>>>>>>>> e4-dev mailing list
>>>>>>>>> e4-dev@xxxxxxxxxxx
>>>>>>>>> https://dev.eclipse.org/mailman/listinfo/e4-dev  
>>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________  
>>>>>>>> e4-dev mailing list
>>>>>>>> e4-dev@xxxxxxxxxxx
>>>>>>>> https://dev.eclipse.org/mailman/listinfo/e4-dev  
>>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________  
>>>>>>> e4-dev mailing list
>>>>>>> e4-dev@xxxxxxxxxxx
>>>>>>> https://dev.eclipse.org/mailman/listinfo/e4-dev  
>>>>>>>
>>>>>> _______________________________________________  
>>>>>> e4-dev mailing list
>>>>>> e4-dev@xxxxxxxxxxx
>>>>>> https://dev.eclipse.org/mailman/listinfo/e4-dev  
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> e4-dev mailing list
>>>>> e4-dev@xxxxxxxxxxx
>>>>> https://dev.eclipse.org/mailman/listinfo/e4-dev
>>>>>
>>>>
>>>> _______________________________________________
>>>> e4-dev mailing list
>>>> e4-dev@xxxxxxxxxxx
>>>> https://dev.eclipse.org/mailman/listinfo/e4-dev
>>>>
>>>
>>> _______________________________________________
>>> e4-dev mailing list
>>> e4-dev@xxxxxxxxxxx
>>> https://dev.eclipse.org/mailman/listinfo/e4-dev
>>>
>> _______________________________________________
>> e4-dev mailing list
>> e4-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/e4-dev
>>  
> 
> _______________________________________________
> e4-dev mailing list
> e4-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/e4-dev
> 



Back to the top