TreeTableFormat

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

TreeTableFormat

Jesse Wilson
The tree stuff looks great so far.

 - I'd prefer to separate Tree from Table as much as
   possible in the interfaces. That allows us to specify
   the structure and the tabularity in 2 different places,
   which is very useful:
        1. Use multiple structure strategies with the same
            tabulation strategy, for example - if you have
            java packages sometimes you want the structure
            to collapse redundant packages so something like
            ca.odell.glazedlists is either 3 nodes or 1
         2. Use multiple tabulation strategies with the same
             structure. For example, there's a universal structure
             of a filesystem, but you may want different sets of
             columns to choose from in different views, such
             as a file chooser view vs. a song chooser view
         3. Leave the door open for JTree support

 - you're using height() where you probably mean depth.
    http://en.wikipedia.org/wiki/Binary_tree

But it looks awesome dude, I'm really stoked about this.

Cheers,
Jesse

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: TreeTableFormat

James Lemieux
Yeah,

   I think it's a decent idea. We'll leave TableFormat the way it is today and I'll define TreeFormat as a separate interface. If we ever wanted, we could glue to two together at a later time in some sort of "uber interface." But for the time being separating them seems fine.

   I'll change height to depth. Makes more sense.

   And, lastly, we are starting to have examples at work here where we simultaneously want two tree views on the same data:

- one that is the true representation of the "collapse / expand" state of each hierarchy node. (for actual display in a tree table)
- one that is a fake representation of the "collapse / expand" state where each heirarhcy node is expanded. (for use when printing a tree or exporting the tree... our users want all data, not the currently set expand/collapse state in the UI)

We should keep that use case in mind while we test, as I think it is common. Theoretically it should mean that decorating the user's given TreeFormat with one that always returns "true" from isExpanded(rowObject) when rowObject is not a leaf would probably do the trick. But perhaps it has other problems I can't see...

J

On 7/17/06, Jesse Wilson <[hidden email]> wrote:
The tree stuff looks great so far.

- I'd prefer to separate Tree from Table as much as
   possible in the interfaces. That allows us to specify
   the structure and the tabularity in 2 different places,
   which is very useful:
        1. Use multiple structure strategies with the same
            tabulation strategy, for example - if you have
            java packages sometimes you want the structure
            to collapse redundant packages so something like
            ca.odell.glazedlists is either 3 nodes or 1
         2. Use multiple tabulation strategies with the same
             structure. For example, there's a universal structure
             of a filesystem, but you may want different sets of
             columns to choose from in different views, such
             as a file chooser view vs. a song chooser view
         3. Leave the door open for JTree support

- you're using height() where you probably mean depth.
    http://en.wikipedia.org/wiki/Binary_tree

But it looks awesome dude, I'm really stoked about this.

Cheers,
Jesse

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: TreeTableFormat

Jesse Wilson
Hey James ---

What if the thing that stored collapsed/expanded
state was separate. Call it a 'TreeExpandModel'
and we'll have an interface like so:

interface TreeExpandModel {
   boolean isExpanded(Object element);
   void setExpanded(Object element, boolean expanded);
}

There's a few nice things about doing it this way -
 1. We can provide a reasonable default that stores
    expanded/collapsed in an IdentityHashMap or similar
 2. Users can store expanded/collapsed on their elements
     if they prefer
 3. Advanced users may want to maintain multiple
    different expanded/collapsed states for the same data.
    In particular, consider the ultimate file browser. On a
    multiuser system, it should remember the expanded/collapsed
    state separately for each user.

The next logical progression of this idea is the observable
expanded/collapsed manager, so users can tell nodes
to reveal themselves and the UI listens to the change and
expands the UI to fit.

For each display (ie. each tree table), we manage a
FilterList-like thing that talks to the TreeExpandModel
to manage which elements are visible.

The regular limitation of not supporting multiple instances
of the same value in the same tree applies here.

Cheers,
Jesse

On 7/18/06, James Lemieux <[hidden email]> wrote:

> Yeah,
>
>    I think it's a decent idea. We'll leave TableFormat the way it is today
> and I'll define TreeFormat as a separate interface. If we ever wanted, we
> could glue to two together at a later time in some sort of "uber interface."
> But for the time being separating them seems fine.
>
>    I'll change height to depth. Makes more sense.
>
>    And, lastly, we are starting to have examples at work here where we
> simultaneously want two tree views on the same data:
>
> - one that is the true representation of the "collapse / expand" state of
> each hierarchy node. (for actual display in a tree table)
> - one that is a fake representation of the "collapse / expand" state where
> each heirarhcy node is expanded. (for use when printing a tree or exporting
> the tree... our users want all data, not the currently set expand/collapse
> state in the UI)
>
> We should keep that use case in mind while we test, as I think it is common.
> Theoretically it should mean that decorating the user's given TreeFormat
> with one that always returns "true" from isExpanded(rowObject) when
> rowObject is not a leaf would probably do the trick. But perhaps it has
> other problems I can't see...
>
> J
>
>
> On 7/17/06, Jesse Wilson <[hidden email]> wrote:
> >
>  The tree stuff looks great so far.
>
>  - I'd prefer to separate Tree from Table as much as
>    possible in the interfaces. That allows us to specify
>    the structure and the tabularity in 2 different places,
>    which is very useful:
>         1. Use multiple structure strategies with the same
>             tabulation strategy, for example - if you have
>             java packages sometimes you want the structure
>             to collapse redundant packages so something like
>             ca.odell.glazedlists is either 3 nodes or 1
>          2. Use multiple tabulation strategies with the same
>              structure. For example, there's a universal structure
>              of a filesystem, but you may want different sets of
>              columns to choose from in different views, such
>              as a file chooser view vs. a song chooser view
>          3. Leave the door open for JTree support
>
>  - you're using height() where you probably mean depth.
>     http://en.wikipedia.org/wiki/Binary_tree
>
> But it looks awesome dude, I'm really stoked about this.
>
> Cheers,
> Jesse
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> [hidden email]
> For additional commands, e-mail:
> [hidden email]
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]