[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [ecf-dev] A model proposal
|
Hey Scott -
I like your idea. To make sure I understand, this approach would
allow someone to create presence logic without an UI. So there would
be no dependencies on SWT. Is this correct? I see this as valuable
as it increases the type of applications that can utilize the ECF
presence logic.
-ken
On Dec 18, 2006, at 2:07 PM, Scott Lewis wrote:
Hi Folks,
In response to bugs:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=167363
https://bugs.eclipse.org/bugs/show_bug.cgi?id=166670
and https://bugs.eclipse.org/bugs/show_bug.cgi?id=166675
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 classes).
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)
AND
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?
Thanks,
Scott
_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev
