I updated https://bugs.eclipse.org/bugs/show_bug.cgi?id=406307 with the question and the answer of John to which all seem to agree.
2013/7/12 Toedter, Kai <[email protected]> > Hi Folks,**** > > ** ** > > I agree with Lars & John. **** > > ** ** > > The classes specified in the views extension are either POJOs or implement > IViewPart. If they are POJOs, they are wrapped into a generic ViewPart, > like Tom did in his “Forward Compat Layer”. I guess this is a good approach > if we want to use “new” e4 things in an existing 3.x RCP application, like > the IDE.**** > > ** ** > > I am more worried about the other way around: How to reuse old 3.x views > in a native e4 application?**** > > Meaning the application skeleton is using the application model, but there > are some “legacy” views using EPs. These views then have to be integrated > using the compatibility layer until they are ported to native e4.**** > > ** ** > > Best regards,**** > > ** ** > > Kai**** > > ** ** > > *From:* [email protected] [mailto:[email protected]] *On > Behalf Of *Lars Vogel > *Sent:* Freitag, 12. Juli 2013 08:44 > *To:* E4 Project developer mailing list > *Subject:* Re: [e4-dev] E4 Extension Points**** > > ** ** > > > This approach won't be usable in 'pure' e4 rcp apps because the EP's > reference IDE classes like ViewPart...**** > > ** ** > > If we go the way John suggested, the POJOs would also be reusable in > Eclipse 4 RCP applications. This would also allow us to migrate existing > org.eclipse.ui views like progress with less effort. **** > > ** ** > > 2013/7/11 Eric Moffatt <[email protected]>**** > > Hi folks, thanks for the input. I think I need to partially re-state the > question... > > There's little doubt that option 1 will be done for allowing the ability > to contribute e4 bits into the IDE -- but -- > > This approach won't be usable in 'pure' e4 rcp apps because the EP's > reference IDE classes like ViewPart... > > ...so...should we also supply e4-specific extension points for common > elements or leave the fragment / model processing as the only way to > contribute to e4 apps ? > > Eric > > [image: Inactive hide details for Patrick Paulin ---07/11/2013 01:18:34 > PM---I agree with Lars that option 1 is better. But is there a]Patrick > Paulin ---07/11/2013 01:18:34 PM---I agree with Lars that option 1 is > better. But is there a reason we couldn't specify a POJO in the n**** > > **** > > From:**** > > > Patrick Paulin <[email protected]>**** > > **** > > To:**** > > > E4 Project developer mailing list <[email protected]>, **** > > **** > > Date:**** > > > 07/11/2013 01:18 PM**** > > **** > > Subject:**** > > > Re: [e4-dev] E4 Extension Points**** > > **** > > Sent by:**** > > > [email protected]**** > ------------------------------ > > > > > I agree with Lars that option 1 is better. But is there a reason we > couldn't specify a POJO in the normal view "class" attribute? Whether the > class implements IViewPart or is a POJO that needs to be wrapped seems like > an implementation detail. > > --- Patrick > > On Jul 11, 2013, at 4:34 AM, Lars Vogel <[email protected]> wrote:**** > > My understanding of 1.) is that the framework would accept Pojos. In would > allow a smooth migration of the existing Eclipse IDE plug-in projects. > > > > 2013/7/11 Jonas Helming <[email protected]> **** > > Hi, > I agree with Lars. However, even option 1 seems like a duplication of > fragments and processors to me. The main disadvantage for me would be, that > you still stick to the old API. What is the advantage? > Regards > Jonas > > Am 11.07.2013 11:22, schrieb Lars Vogel: **** > > Hi Eric, > > I think 1.) would be the right thing. 2.) feels like a duplication of > model fragments and model processors to me. > > Best regards, Lrs > > > 2013/7/10 Eric Moffatt <[email protected]> **** > > I'm currently looking at what we're going to do as far as extension points > go to enable folks to contribute e4 (DI) code into the IDE and I want to > get some feedback from the e4 community as to the best way for me to do > this... > > I have two possible approaches: > > 1) Extend the current IDE extension points with e4-specific sections (i.e. > extend the existing org.eclipse.ui.views EP to allow the addition of 'e4 > View') > 2) Provide separate extension points for the e4 bits (i.e. clone the > existing org.eclipse.ui.views EP and tweak it to be e4-related > > Do you *want* e4 specific extension points ? This is independent of having > the ability to contribute them through fragment / model processing (which > we'll also be working on in Luna). The BOF at last year's eclipsecon didn't > come to a resolution on this (at least not one that I remember..;-). > > Let me know what you think, > Eric > > > _______________________________________________ > e4-dev mailing list* > *[email protected]* > *https://dev.eclipse.org/mailman/listinfo/e4-dev**** > > > > > _______________________________________________ > e4-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/e4-dev**** > > > > _______________________________________________ > e4-dev mailing list* > *[email protected]* > *https://dev.eclipse.org/mailman/listinfo/e4-dev**** > > > _______________________________________________ > e4-dev mailing list* > *[email protected] > https://dev.eclipse.org/mailman/listinfo/e4-dev**** > > > > > _______________________________________________ > e4-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/e4-dev > > **** > > > _______________________________________________ > e4-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/e4-dev**** > > ** ** > > _______________________________________________ > e4-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/e4-dev > >
<<image001.gif>>
<<image003.png>>
<<image004.png>>
_______________________________________________ e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/e4-dev
