[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [e4-dev] Horizontal extension possibility for e4 tooling
|
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 (tom.schindl@xxxxxxxxxxxxxxx) 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 (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
> >
>
> _______________________________________________
> e4-dev mailing list
> e4-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/e4-dev
>