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

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
>  



Back to the top