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. [1]

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.

Data-Access API:
 - 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 [1]
> [1] http://markmail.org/message/vu3jqmlawrskplic
> ~~~
> some further thoughts:
> For example, in Estatio there are several hierarchies
> EstatioInstance ("global") /
>   EstatioInstance ("italy") /
>     EstatioInstance ("Roma shopping mall")
> or:
> Property/
>   Floor/
>     Unit
> 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

Reply via email to