Re: [platform-ui-dev] Fwd: Generification of the JFace TreeViewer

[Markus Keller <markus_keller@xxxxxxxxxx>]

I don't have a good solution and the Gerrit link doesn't work for me (page 
not found or no permission to view).

But I just wanted to point out that AbstractTreeViewer is API, and 
although TreeViewer is marked as @noextend, we know that many clients had 
to extend it to solve performance problems. Therefore, I'd be very 
reluctant to change call sequences or add more methods that are overridden 
by subclasses.

It's probably better to use some unchecked casts to E to satisfy the type 
system, but still funnel TreePath objects through methods that should only 
operate on Es. However, this can only work as long as you're sure that the 
erasure of such method still stays Object in the signature. You have to do 
some real-life experiments to be sure that casts in bridge methods don't 
hit you at run time.

Markus

Hendrik Still <hendrik.still@xxxxxxxxx> wrote on 2013-08-20 15:41:12:

> Hi,
> 
> I'm currently adding generics support to the JFace TreeViewer, but I'm
> running in to some problems and I thought you could help me with that.
> 
> Unlike the other Viewers, with flat data structures like the
> TableViewer, the TreeViewer has to handle (of course) tree like data
> structures.
> 
> For the viewers in general we decided to have two type parameters for
> every viewer. E for an single element the viewer should display and I
> for the input you set with the setInput method. For example you are
> able to type a TableViewer with TrableViewer<Person,MyOwnListOfPersons>
> This type parameters are also applicable to the TreeViewer, but the
> tree structure and the internal implementation of the viewer does not
> allow a stronger typing of method parameters like it is done in the
> other viewers.
> 
> For example the method isExpandable(Object elementOrTreePath) in the
> AbstractTreeViewer class. This method handles elements (typed as E),
> the input (typed as I) and additional to that a TreePath(typed as
> TreePath) for the ITreePathContentProvider. The handling for the
> different types are managed at runtime. Also this works fine with
> generics, the problem is the call of the getFilteredChildren(I parent)
> method from the superclass(StructuredViewer). The getFilteredChildren
> method is not only called with as I typed parameters, but also with E
> and TreePath typed parameters. The signature of the
> getFilteredChildren method is correct for all viewers, except for
> TreeViewer.
> 
> After consulting my mentor Lars Vogel, my first try was to override
> the getFilteredChildren method in the
> AbstractTreeViewer class with the signature getFilteredChildren(Object
> parent), which called the getRawChildren method of the
> AbstractTreeViewer. But to still execute the filters which could not
> be accessed from the AbstractTreeViewer, I had to outsource the filter
> functionality to another protected method (internalFilter) which can
> be called from the subclass.
> 
> You can see my currently running changes at
> https://git.eclipse.org/r/#/c/15647/
> 
> So what do you think? Is this a acceptable solution for the issue?
> 
> Regards,
> Hendrik