[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[eclipse-incubator-e4-dev] Client/Server Split
|
Hi,
One item that immediately tracked my attention is the Client/Server
split. Is it what I think it is? ;)
A while back I started hacking together some code to "model" UIs.
However, the model is not as low level as SWT. Instead it's on a higher
level. The reason is that I wanted to reduce complexity for the
developers which eventually would use it to model their UIs.
The UIs I'm talking about are UIs often found on typical "back-office"
web UIs, i.e. pages with forms to fill out, lists and tables to display
and some dynamic JavaScript effects to avoid complete page reloads and
to improve the usability.
I made the experience not every developer in a team is comfortable of
hacking Java, HTML and JavaScript at the same time to build such UIs. In
fact, only 3 out of 10 developers are comfortable with. That's why I
started thinking (and coding) this "model".
The most important part of my idea is simplicity. Thus, the model does
not including a layout requirement. The rendering container is
responsible for providing a default layout and customization/styling
capabilities. But they are strictly separated from the UI defined by a
developer. The developer also should not need to think about data
binding between server and client.
The UIs are defined on the server. They are delivered to a client. The
client can be a browser or an RCP application (on a different or within
the same JVM). Of course, it could also be a DotNET or some other
proprietary technology talking over a custom protocol. Those
implementations are just "plugged" into the server. It's one model for
all "clouds".
The definition for a developer could be as simple as:
https://cloudfree.net/svn/trunk/doc/example1-container.png
which results into something rendered in a browser like this:
https://cloudfree.net/svn/trunk/doc/example1-gwt-rendered.png
Of course, there are many things not yet implemented (eg. field
decorations, tables, lists, etc.). The first browser "renderer" is
implemented using GWT. There can also be a RAP (or an SWT/DOJO?)
renderer as well. I did start prototyping and RCP Forms UI based
rendered but haven't had time yet to complete it.
I wanted to reach out to give you something to explore and to throw in
yet-another-idea for e4. I don't think that such a higher level model
should be used to rebuild the entire Eclipse IDE. This is out of scope.
However, I do think that it's something that a lot RCP folks might be
interested in.
Of course, there are use cases where more specialization is necessary
which satisfy the need for a full RCP client. Don't think of this
"model" as a replacement for RCP but as a possibility to share some
common grounds between the RCP and Web world.
If you want to have a look the code please don hesitate. It's licensed
100% under EPL.
https://cloudfree.net/svn/trunk/
-Gunnar
--
Gunnar Wagenknecht
gunnar@xxxxxxxxxxxxxxx
http://wagenknecht.org/