[ https://issues.apache.org/jira/browse/ISIS-898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16547429#comment-16547429 ]
ASF subversion and git services commented on ISIS-898: ------------------------------------------------------ Commit daca965c2d18b721cc2a87d96918ad8fd14b44a8 in isis's branch refs/heads/master from danhaywood [ https://gitbox.apache.org/repos/asf?p=isis.git;h=daca965 ] ISIS-898: fixes classcast exception with TreePanel. The FixtureResult class (view model returned from running fixture scripts through the UI) has a property of type java.lang.Object - this being the object wrapped by the FixtureResult, created by the fixture script. The logic in TreePanelFactories to determine if this property's type implements TreeNode seems to be wrong - returns yes for Object being a subtype of TreeNode. This then causes a TreePanel to attempt to be rendered which looks to downcast the object to TreeNode, and then that fails. > 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 > Assignee: Andi Huber > Priority: Minor > Fix For: 2.0.0-M2 > > Attachments: tree.png > > > 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 (v7.6.3#76005)