[
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-----