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

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 <marco@xxxxxxxxxx> 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<AbstractElementEditorContribution> 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


Back to the top