- 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.
--
[email protected]
http://www.pst.ifi.lmu.de/~rauschma/
_______________________________________________
e4-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/e4-dev
