Skip to main content

[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



Back to the top