[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [e4-dev] Horizontal extension possibility for e4 tooling
|
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
>
