[
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
>