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]<mailto:[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 [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]<mailto:[email protected]>> To: E4 Project developer mailing list <[email protected]<mailto:[email protected]>>, Date: 07/11/2013 01:18 PM Subject: Re: [e4-dev] E4 Extension Points Sent by: [email protected]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[email protected]> https://dev.eclipse.org/mailman/listinfo/e4-dev _______________________________________________ e4-dev mailing list [email protected]<mailto:[email protected]> https://dev.eclipse.org/mailman/listinfo/e4-dev _______________________________________________ e4-dev mailing list [email protected]<mailto:[email protected]> https://dev.eclipse.org/mailman/listinfo/e4-dev _______________________________________________ e4-dev mailing list [email protected]<mailto:[email protected]> https://dev.eclipse.org/mailman/listinfo/e4-dev _______________________________________________ e4-dev mailing list [email protected]<mailto:[email protected]> https://dev.eclipse.org/mailman/listinfo/e4-dev _______________________________________________ e4-dev mailing list [email protected]<mailto:[email protected]> https://dev.eclipse.org/mailman/listinfo/e4-dev
<<inline: image001.gif>>
<<inline: image003.png>>
<<inline: image004.png>>
_______________________________________________ e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/e4-dev
