pivot-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roger Whitcomb (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (PIVOT-933) Allow refusal to open a TreeView branch
Date Fri, 20 Dec 2013 21:50:10 GMT

    [ https://issues.apache.org/jira/browse/PIVOT-933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13854592#comment-13854592

Roger Whitcomb commented on PIVOT-933:

I also want to change the return value of "TreeView.setBranchExpanded" to be "boolean" so
the result of the vote can be returned (in other words, whether or not the branch expand state
actually changed).  Although, this is inconsistent with Rollup expansion (for instance), although
an argument could be made for changing those other methods as well.

So, I will hold off on this change for further thought.  The Vote result could be returned
instead of a boolean (since it is a tri-state result).


> Allow refusal to open a TreeView branch
> ---------------------------------------
>                 Key: PIVOT-933
>                 URL: https://issues.apache.org/jira/browse/PIVOT-933
>             Project: Pivot
>          Issue Type: Improvement
>          Components: wtk, wtk-terra
>    Affects Versions: 2.1
>         Environment: All
>            Reporter: Roger Whitcomb
>            Assignee: Roger Whitcomb
>            Priority: Minor
>             Fix For: 2.1
> In some cases (i.e., doing lazy loading of contents of a tree branch) an error might
occur that precludes getting the information for the branch.  In this case it would be better
to simply refuse to open the branch because the information is inaccurate or not available,
rather than show a (potentially misleading) empty list.
> This is a simple change to add a method to TreeViewBranchListener called "previewBranchExpandedChange"
that returns a Vote as to whether or not to expand/collapse the branch, similarly to the way
Rollups and Accordions work.  The Adapter will return Vote.APPROVE so (most) existing apps
will continue to work as before (unless they directly implement the TreeViewBranchListener
interface instead of subclassing the Adapter).  Will also need to implement the "branchExpandedChangeVetoed"
method to be consistent (although there is currently no use for it in the skin).
> Adding this in a point release (2.1) instead of a maintenance release (2.0.4) because
the API is changing.

This message was sent by Atlassian JIRA

View raw message