Andi Huber commented on ISIS-898:
I'm now in the need of rendering tree data for one of my projects. Good thing
is, it's not urgent, so I have time to do it right.
First of all we'd need a good general purpose API for tree-data structures that
could be added to applib. Similar to Java's Collection interface, which - as
already supported by Isis - is a good interface for list/set data-structures,
we need an equivalent for trees.
We could invent an interface 'TreeModel' such that Isis will render these
utilizing Apache Wicket's Tree Widgets. 
To simplify matters, we could treat this 'TreeModel' as a 'lazy view-model',
and refrain from providing any persistence mechanics for it. And by lazy I
mean, that by default only the root of the tree is rendered (with every child
collapsed, unless programmatically intended otherwise) and hence only a single
node needs to be fetched for rendering by the client by default initially. Any
expanding of tree-nodes will trigger a new Ajax request, to fetch only those
tree-nodes that are actually visible.
- depth-first/breadth first tree-node iteration/streaming of tree-nodes
- hierarchy-up tree-node iteration/streaming of tree-nodes (walking the parent
chain of a tree-node)
In addition to that the visual appearance needs some basic API as well, such as:
- expand/collapse a tree-node (programmatically)
- decorate a tree/node (e.g. to put an overlay on a tree-node's icon)
- showing/hiding tree-nodes (are rendered or not)
- enabling/disabling tree-nodes (are expandable or not)
Clearly this is just a brainstorming, we should investigate other frameworks
and collect some good ideas.
*Comments are highly appreciated!*
> Add a table tree view to the Wicket viewer.
> Key: ISIS-898
> URL: https://issues.apache.org/jira/browse/ISIS-898
> Project: Isis
> Issue Type: New Feature
> Components: Core: Viewer: Wicket
> Affects Versions: viewer-wicket-1.6.0
> Reporter: Dan Haywood
> Priority: Minor
> Fix For: 3.0.0
> see mailing list discussion 
>  http://markmail.org/message/vu3jqmlawrskplic
> some further thoughts:
> For example, in Estatio there are several hierarchies
> EstatioInstance ("global") /
> EstatioInstance ("italy") /
> EstatioInstance ("Roma shopping mall")
> We'd like to render these objects in a single tree/table collection.
> We should distinguish two cases:
> - where all the rows are of the same type (EstatioInstance, turtles all the
> way down).
> - where all the rows are of different types (Property/Floor/Unit)
> For the former, the columns to use are exactly those of the (single) class.
> For the latter, things are more complicated, as all the objects are of
> different class. It's not clear to me what (apart from an icon and a title)
> should be shown as columns. Perhaps just the intersection of those
> properties that are common across all types (eg name?) . Or perhaps there's
> metadata (in @PropertyLayout(...)) to specify that a particular property
> should always be shown in such tree/table collections, even if it is null for
> other rows for instances of some other class.
This message was sent by Atlassian JIRA