Would be nice to have the option to mix the old things with the new ones. And +1 for using E4. The term "Eclipse Application Platform" did get any leverage with people outside the inner Eclipse circle IMHO.
2011/12/5 Brian de Alwis <[email protected]> > I've been helping a company to move their application suite from a > homegrown Swing-based application framework onto Eclipse. In discussions, > I've come to realize that our messaging around the compat layer is causing > some confusion, and I think we should adapt our story around the compat > layer. > > This company's goals are to leverage the extensibility of the Eclipse > platform to open up their suite to extension by their customers. They're > really excited by the CSS styling, DI, and the IEclipseContext. Although > their application suite is very well-suited to the E3.x UI model (views, > editors), and they really like some of the E3.x UI technologies (e.g., > cheat sheets, intro), our use of "compatibility layer" is off-putting: the > implication is` that it's strictly for legacy applications that cannot be > converted the E4 APIs, and not recommended for new green-field development. > Since their transition will be a big effort that they hope will carry > their suite for the next 5-10 years, they don't want to move to something > perceived as being "yesterday's technology". But to implement what they > want on a pure E4 foundation will effectively re-create the compat layer, > which seems rather counter-productive. > > In thinking about it a bit, I realized that the real achievement of the > E4AP effort has been to split the Eclipse UI mechanisms from the UI > policies. Eclipse 3.x implemented a particular UI paradigm based around > strong notions of views and editors, but it was a poor fit for apps that > don't want to buy in to that UI paradigm. With Eclipse 4, apps can > implement their own UI paradigms, like I did for Kizby. Seen in this > light, the compat layer is really an implementation of such a UI paradigm. > > My suggestion is that we should re-cast the compat layer as an "E3.x UI > Paradigm" or "E3.x UI Policy layer" or "E3.x UI Framework" (vs platform), > or something to that effect. I personally like "framework" as a > counterpoint to a "platform" — it implies any app written to the E4AP layer > will likely require writing some plumbing to implement their own UI > framework onto the minimalist policies defined by the platform. Our E3.x > UI framework then has two parts, one implementing the E3.x UI model using > the E4 platform, and the other being a translation layer for older > configuration methods into the E4 equivalents (e.g., the UI extension > points, action sets). > > To that effect, I think we should (and I will) start documenting how the > compatibility layer (or whatever we call it) works, such as the expected > tags on parts to distinguish an editor from a view, and how a more > E4-focused plugin can safely interact with the E3.x UI Policy layer. After > all, it would be great for devs to be able to develop against the > App.e4xmi. Perhaps we should have a PerspectiveDescriptor? > > [And while I've brought up naming, perhaps we should accept that the > e4/E4AP distinction has been lost for ever, and we should just call the > E4AP as "E4", like others are?] > > Brian. > > _______________________________________________ > e4-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/e4-dev > -- Lars http://www.vogella.de - Eclipse, Android and Java Tutorials http://www.twitter.com/vogella - Lars on Twitter
_______________________________________________ e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/e4-dev
