Re: [ecf-dev] A model proposal
Catching up on email after getting back from vacation and all I can say for this one is a big +1, this would definitely make life easier for UI developers.
Chris Aniszczyk | IBM Lotus | Eclipse Committer | +1 860 839 2465
Scott Lewis ---12/18/2006 01:13:50 PM---Hi Folks,
|From:||Scott Lewis <slewis@xxxxxxxxxxxxx>|
|To:||"Eclipse Communication Framework (ECF) developer mailing list." <ecf-dev@xxxxxxxxxxx>|
|Date:||12/18/2006 01:13 PM|
|Subject:||[ecf-dev] A model proposal|
In response to bugs:
I've been working with the ECF presence API and thinking about ways to
simplify the creation of user interfaces for viewing the roster and
other data structures that are shared...i.e. they change based upon
things happening remotely...like buddies being added/removed in the case
of the presence roster.
So I had the following thought: Why not push down the model
creation/change into the ECF provider? Currently, the local UI-visible
copy of the roster, for example, is actually created and maintained
within the UI code (in an ITreeContentProvider). The content is updated
via callbacks/listeners registered by the UI (e.g. IPresenceListener,
etc). This is clumsy, in that it requires the UI code to 'do alot' to
create and update a local model (e.g. ITreeContentProvider) for
viewing/rendering by the user interface (e.g. RosterView).
A better way, I believe, would be to define an abstract model for the
roster, consisting of IRosterManager, IRoster, IRosterGroup,
IRosterEntry, and IPresence interfaces that expose only the *read*
access necessary to allow the ITreeContentProvider to display and
navigate a given roster (in a treeviewer for example). The provider
would be responsible for creating/manipulating the roster model in
response to both remote events (e.g. server or peer says add buddy to
roster). This way, the user interface code can be *much* simpler, and
concentrate on rendering the model via calls to the content provider
without having to know anything about the structure of the actual model
underneath the content provider. Further, the provider would have to
manage the asynchronous state changes to the model, and so it would be
unnecessary for the UI code to have to worry about whether a given
method was being called by a non-UI thread.
So to give these thoughts some 'meat' I've implemented an abstract
'roster' model (in org.eclipse.ecf.presence.roster.* package...in
IRosterManager, IRoster, IRosterGroup, IRosterEntry, and IPresence in
that directory). Notice that the methods here have *no*
knowledge/dependencies on UI code at all. There's also a new plugin:
org.eclipse.ecf.presence.ui, that defines some UI interface based upon
ITreeContentProvider (and ILabelProvider) and some implementation
classes (e.g. RosterContentProvider...these depend upon org.eclipse.ui
What this allows, I think, is the ability to have:
1) a UI-less interface to the underlying model for a roster (e.g.
IRosterManager, IRoster...etc.)...based upon the model defined in
org.eclipse.ecf.presence.roster.* (think servers)
2) it allows developers that want to easily create a jface UI for a
roster to do so by reusing all the same model interfaces and by using
new code in org.eclipse.ecf.presence.ui (with content providers, basic
views, etc that we can/will create)
In essence it creates a much looser coupling between the 'shared model'
and the user interface code.
Please let me know what you think. If people think this is a reasonable
approach/an improvement then I would recommend that we move to
a) Implementing this new 'model-based' interface in existing providers
(xmpp and then jxta
b) Creating new, simpler, more extensible rosterview UI code based upon
this approach (in org.eclipse.ecf.presence.ui).
and then deprecate the old code in org.eclipse.ecf.presence (the roster
stuff), and the UI code in org.eclipse.ecf.ui.views
What do people think?
ecf-dev mailing list