Results 1 to 2 of 2

Thread: Different class types for TreeGrid parents/children

  1. #1
    Sencha User
    Join Date
    Nov 2012
    Vote Rating

    Default Different class types for TreeGrid parents/children


    My application has the need to include different data types for TreeGrid children and parents.
    If doing so it will give problems when creating the column models. However using a single data type for two different concepts, namely children and parents, is not nice.

    So, does there exist a way to overcome this problem or if not a justification why it is restricted to a single data type?

    Kind regards,

  2. #2
    Sencha User
    Join Date
    Feb 2009
    Vote Rating


    There is nothing that restricts the TreeGrid (or Tree, or the TreeStore itself) form holding more than a single type, but you need to refer to the highest possible type when building these objects. Then, in anything that needs to behave differently depending on type, that code must clearly do a type check.

    For a time in the development of 3.0, we considered allowing each level in the tree store to be a new type, but that causes other interesting requirements. Generics, for example, get tricky - you wouldn't want a TreeStore<Country, State, County, City, Street>, and Java doesn't allow an arbitrary number of levels anyway. Or, we could have done this the other way - define each type to implement some interface Node<P,C>, where P is the parent type, and C is the child. Then Country implements Node<Void, State>, State implements Node<Country, City>, etc.

    This quickly gets ugly for cases where nodes do *not* have a hierarchy, but files can be in folders, and folders can be in more folders - how could that be defined?

    And finally, how many Cells would need to be defined per-column? Do we just look for Node<?,?> and leave the typechecks to you, or do we accept a chain of Cells, each generic based on the last, or just blindly accept raw Nodes, and leave it to developers to make sure that these types make sense?

    So we abandoned this idea, and instead allow the TreeStore data to be described as any one type. You are free to build your own such interface system, and then cast or typecheck anything coming out of the tree to know what the parents or children will need to be.

    Most of the Tree and TreeGrid examples in the explorer use this idea - they have a BaseDto class that declares two things - an ID, because all nodes must have unique IDs (though here we make them unique by type by adding a prefix), and each node has a name. Then, for each other column drawn in the TreeGrid, the ValueProvider picks a specific value, based on the type of the node (i.e if Folder, return "", if Music, return obj.getComposer(), etc). The TreeStore then is TreeStore<BaseDto>, and the TreeGrid is generic on BaseDto as well. We've tried very hard to use the 'super' keyword where appropriate, so if you define a ValueProvider<BaseDto, String>, you can use it anywhere a ValueProvider<MusicDto, String> is accepted (since BaseDto is the superclass of MusicDto), but not vice versa.

    I hope this makes sense and clarifies the particular way of dealing with types we elected to go with. If you can outline your problem a little more clearly, I hope we can try to find a way to make it work with this system.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts