Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [e4-dev] Introduction

Hi Arthur,

Welcome to e4!

> The project goes along with my interest areas (specially when you
> talk about "running desktop UI components in web environments", and
> "pulling web concepts into desktop development").

Yes - wouldn't it be great if you could write UI components once and then reuse them in a web UI and a desktop UI?

Our current direction for the first area "running desktop UI components in web environments" is called SWT/BE - being able to write Java against normal SWT APIs, which is then cross-compiled to _javascript_ (in the case of the SWT port to Dojo), ActionScript (in the case of the SWT port to Flex), or other target environments such as e.g. Silverlight.

I am currently looking at the second area "pulling web concepts into desktop development" and have a prototype of a web component running as an editor in Eclipse.

Of course there is more to this than just getting the SWT code to run in a browser, or getting a web page to show up inside a desktop UI. You'd want that UI component integrated properly in its context. For example, my prototype "web component" editor, when dirty, should show a dirty indication in the Eclipse editor tab, and selecting File>Save should trigger the web UI's save function.

On a more abstract level, if you want a UI component to be usable in the desktop and the web context, it needs to talk to its environment through well-defined interfaces that work in both cases. My current thinking is that dependency injection of services is the way to go. This means that components may not "reach out" to outside objects, such as singletons like PlatformUI.getWorkbench(). Furthermore, you'd want to avoid interfaces which give access to many other services. Components will be usable in more contexts if they talk to fine-granular services instead. For example, instead of making IWorkbench available as a service, from which you can getProgressService(), getOperationSupport(), getHelpSystem(), etc., you would make IProgressService, IOperationSupport, IHelpSystem etc. available directly (for example through dependency injection), and nobody would ever need to access the IWorkbench object itself.

In the case of a web component, another problem is making services available in _javascript_ instead of Java, but we said that e4 should have API that can be used from other languages anyway.

If you are interested in working on these topics together that would be great. My "current thinking" wiki page is:

I am curious to know what your background is and what (if anything) you have done in this area so far. Maybe there are others on this list who are interested in the area as well?


Back to the top