[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [nebula-dev] [CompositeTable] Selection/Check + Viewer API
|
Thanks for your comments, Tom and André. I think that I can get
CompositeTableViewer to fit under the Viewer hierarchy after all.
After digging into the source code of the whole hierarchy, I think
that my obsession with the Item type may have been misleading. I
realize now that most of the Item-related logic is down below
ColumnViewer, and CT is not a column-based Control. CTV belongs
right beneath StructuredViewer and should have an implementation
similar to AbstractListViewer + ListViewer. These classes have
already solved issue #1 (from my original email) by simply returning
the whole Control from StructuredViewer.doFindItem() and tracking
elements in an ordered List. The same solution should work for CTV.
StructuredViewer has basic support for IStructuredContentProvider,
but it will need to be tweaked slightly so that rows are re-rendered
whenever they scroll into view. (I think SV assumes that it only
needs to update a row if the element changes.) The logic for
ILazyContentProvider is down in AbstractTableViewer. This will need
to be rewritten or modified and pushed up to StructuredViewer so that
CTV can use it. The CT version will be slightly simpler, since it
won't have to worry so much about accidentally creating new Items.
That takes care of issue #4.
AbstractListViewer assumes that each list item can be fully rendered
as a single String, and that is not true for CT. New code will be
needed to solve issue #5 (rendering content with a "label
provider"). I propose:
public interface IControlLabelProvider extends IBaseLabelProvider {
public void update(Object element, Control rowControl);
}
Colors, Fonts, tooltips, etc. must all be managed by the
IControlLabelProvider implementation. It is up to the client code to
decide what to care about.
I'll need to evaluate each of the features from issue #6 one by one
to see whether the StructuredViewer implementation is correct for CT.
ColumnViewer and AbstractTableViewer also support cell editing and
tab navigation styles. The editing styles don't apply to CT, but the
navigation styles might.
--
Peter
On Mar 28, 2007, at 6:21 PM, André Dietisheim wrote:
Hi Peter
sorry for my late response. My spam-filter tagged your mail by
mistake, I
just discovered it.
wow! A whole lot of ideas! I'll need some time to get through all
of them
:-) I was was also thinking about whether it makes sense to have
compositeTable accessible by the viewer api. But I did not get as
concrete
as you did.
My first impression is that replacing item by integer should work,
on the
other hand I feel like this API-break kills most of the benefits
one would
get (effective compliance is broken). The only advantage I still
see is
that people are used to the viewer api and would get into it real
fast. I
totally agree with you that a common model-layer to CT would be a
major
benefit but I am not sure if a mimed viewer API really is the right
choice.
Regards
André
