Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [e4-dev] E4 for Ajax applications?
- Client: Dojo

The prototypical "PDE site.xml editor" (see
http://download.eclipse.org/e4/downloads/drops/R-0.9-200907291930/e4-news-all.html#web2desktop)
uses Dojo client-side. We complemented Dojo with API for a few
higher-level concepts, a small subset of what we call "Eclipse Application
Services" or "the twenty things". This is about being able to integrate
independently developed UI components to form an application, for example
API for an editor to signal that it has unsaved changes, and a callback for
triggering a save.

Cool, this goes a lot further than I thought.

- Client-server communication: via JSON-RPC

The editor I mentioned uses XMLHttpRequest to communicate with the server,
and it uses JSON as the data transport format. Does this count?

I think it does. JSON is cool, because then one can implement some server-side things in _javascript_ and others in Java. It would be neat if the server interface was as standards-based as possible, then one can access the server from non-browser apps, too, hopefully with standard tools. But I don't know how much freedom one has in the browser; XHR + JSON sounds like a reasonable compromise.

- Server-side plugins should be able to contribute client-side
modules. How would this be done? One possibility is for the server-
side modules to contribute server-side directories that are accessible
from the client. This kind of server-side file system contribution
would be desirable for static content (HTML, CSS, images, ...), too.

Using the Jetty/Equinox integration, you can do this already by
contributing server-side directories through extensions. It is not very
elegant though and I would like to hear your ideas on this - can you give
more details on what kind of support you would like to see?

I can think of several use cases:
(1) The plugin brings its own browser-side _javascript_ (=client-side modularity via server-side modularity).
(2) The plugin brings its own HTML, JSP, CSS, etc.
(3) Some server-side files are being exchanged (for configuration etc.), often extension points will suffice here.

I do realize that this is the SWT/Browser Edition approach turned
inside out, but it would give one excellent modularity while having
more control over the GUI in the browser. Plus, server-side language
agnosticism is also a cool feature.

I am not sure I fully understand what you are saying. I get the part about
modularity (but do Ajax developers care about modularity?)

The next version of Hyena is going to be a web application that I will package as a desktop application and as a WAR file. Some of the server-side code will be written in Java, some will be written in _javascript_ (this is why e4 is so appealing).

Once one decides on a _javascript_ GUI layer, it has to be as modular as the backend. And Eclipse's modularity was *great* when I had students contribute to my framework: they tested my API, while being largely independent of my code.

but what do you mean by "more control over the GUI in the browser"?

Compared to using SWT/Browser edition (one more level of indirection = less control). This does not apply to the things you have done with Dojo. With GWT, it is really cool how they have duplicated the complete DOM in Java so that browser-side GWT code can do (almost) everything that raw _javascript_ can.


Back to the top