Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [platform-ui-dev] Fwd: Generification of the JFace TreeViewer 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

It seems that I've uploaded it as draft, which was not my intention.
I'll upload a new patch.

Hendrik

Am 23.08.2013 10:45, schrieb Daniel Megert:
> Why is your change [1] not visible?
> 
> Dani
> 
> [1] https://git.eclipse.org/r/#/c/15647/
> 
> 
> 
> From:        Hendrik Still <hendrik.still@xxxxxxxxx> To:
> "Eclipse Platform UI component developers list." 
> <platform-ui-dev@xxxxxxxxxxx> Date:        23.08.2013 10:36 
> Subject:        Re: [platform-ui-dev] Fwd: Generification of the
> JFace TreeViewer Sent by:
> platform-ui-dev-bounces@xxxxxxxxxxx 
> ------------------------------------------------------------------------
>
> 
> 
> 
> Thanks for the answer. I'm currently fixing some warnings in the
> code and will upload it later as new review. I'll also try to apply
> your suggestion. So your idea is to let the signature
> getFilteredChildren(I parent) as it is and cast the
> "elementOrTreePath" variables to I(the StructuredViewer expects an
> E) to satisfy the type system? I've already tested this, but I
> wasn't sure if this solution will confuse some people.
> 
> Regards, Hendrik
> 
> Am 22.08.2013 16:11, schrieb Markus Keller:
>> 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
> 
>> _______________________________________________ platform-ui-dev 
>> mailing list platform-ui-dev@xxxxxxxxxxx 
>> https://dev.eclipse.org/mailman/listinfo/platform-ui-dev
> 
> 
> _______________________________________________ platform-ui-dev
> mailing list platform-ui-dev@xxxxxxxxxxx 
> https://dev.eclipse.org/mailman/listinfo/platform-ui-dev
> 
> 
> 
> 
> _______________________________________________ platform-ui-dev
> mailing list platform-ui-dev@xxxxxxxxxxx 
> https://dev.eclipse.org/mailman/listinfo/platform-ui-dev
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iQEcBAEBAgAGBQJSFyK4AAoJECjZOs4dIxisSvsH/31VXFqS9Nqm4jD/60FLYXkb
8HNAS7hXwg2JZ2jJq4he4ThfN4ZeLSbeTXSsewttHWDZqFpkBad4crXSb/UwP8DL
9VkymXNNRXylMIzcnzybVYC8aFHzmW7Idj9FcSENY+lgkV8DDwux+BGuzYJh1tC9
tDryui8ITcJ2hsJAxTirHYTGa1r0GLb0QmDbXuCLZSrVeMYbMJu1jrbkSYCnE0ik
3bMeXsFWFQAvKAOKmcb/kD8cff/LBuM89Ysn9j1n8/Zqwlx664GAsziKDuCSR3+2
a41QJJBr3bH49R10vD9A522wwSQwbRqauX5B74w+qJhQ3LqczP36Zx937EzOWTc=
=a/gN
-----END PGP SIGNATURE-----

Back to the top