| Reactions to CompositeTable API [message #569984] |
Thu, 30 November 2006 15:44 |
 Matthew Hall
Messages: 368
Registered: July 2009 |
Senior Member |
|
|
I've been looking over the API for CompositeTable and wanted to share
some of my reactions for discussion.
First of all, this control is a great idea and as evidenced by the
response on the newsgroups, is useful for a fair number of people,
including myself. However the stated goal of Nebula is to be a proving
ground for custom widgets, with the eventual goal of those widgets being
adopted into SWT proper. I think that the CompositeTable API deviates
from SWT conventions to such a degree that will make its adoption into
SWT unlikely. Thus I would like to see CompositeTable refactored to
makes its API more like the rest of SWT.
For example: Table, Tree and TabFolder expose their content through
TableItem, TreeItem and TabItem and developers are used to interacting
with them. By contrast, CompositeTable uses prototyping to define rows
and possibly headers. This is a very unfamiliar approach in Java, let
alone in SWT. I think everyone would be more comfortable with a
CompositeItem concept rather than this nebulous (forgive the pun)
prototyping scheme.
On the same note, the Table and Tree widgets have a method setItemCount
to set the number of items, whereas in CompositeTable this is called
setNumRowsInCollection.
I don't like the design-mode / active-mode paradigm.
Then there is the use of reflection. Although I recognize that Dave
Orme (who authored the control) would be quite comfortable with
reflection, given his role in VE and data binding, I am nonetheless
uncomfortable with it. Using reflection is a performance hit, is
brittle, and really isn't necessary if we just invent an interface to
replace it (ICompositeRowBuilder). Moreover it makes adoption into SWT
impossible since (as I understand it) reflection is not available in the
CDC-1.0/Foundation-1.0 runtime environment.
And I REALLY don't like being forced to extend composite for my rows,
when we could just define an interface that creates and manages a
composite instead. This is a very Swing way of using SWT.
It would also seem more appropriate to use SWT.SetData listeners like
the other virtual controls instead of addRowContentProvider.
Just my $0.02. What does everybody else think?
(Should this be posted in Bugzilla instead?)
Thanks for listening
Matthew Hall
|
|
|
Powered by
FUDForum. Page generated in 0.02834 seconds
] 
Search
Help
Register
Login
Home
