[
https://issues.apache.org/jira/browse/ISIS-993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15095845#comment-15095845
]
ASF subversion and git services commented on ISIS-993:
------------------------------------------------------
Commit 9ebaee6567ac2655b50b5705342b1fd91448ceca in isis's branch
refs/heads/ISIS-993 from [~danhaywood]
[ https://git-wip-us.apache.org/repos/asf?p=isis.git;h=9ebaee6 ]
ISIS-993: working towards getting dynamic reloading working smoothly - not
there yet.
* moved responsibility for reading the XML to ObjectLayoutMetadataFacet (not
certain if that was a good idea).
* Update to MedataMenu to switch on/off dynamic layouts. Don't invalidate
entire spec, instead just reload the metadata.
* EntityModel cloning now shares the assocated ScalarModel map (a shallow
clone), needed for edit form
* ObjectReflectorDefault only eagerly loads specs for contributed services and
mixins, in an attempt to reduce startup time
* EntityTabGroupsPanelFactory now created ether the EntityTabGroupsPanel or the
original EntityCombinedPanel, depending on whether there is layout.xml metadata
* added some further convenience methods to ObjectLayoutMetadata.
What I would like to do is to eagerly load up the layout.xml up front rather
than lazily. However, attempting to do that caused a stackoverflow, and not
sure why. As things stand I also have an issue with edit failing for the
todoapp if no layout data at all, not sure why.
> Show different object members on multiple tabs
> ----------------------------------------------
>
> Key: ISIS-993
> URL: https://issues.apache.org/jira/browse/ISIS-993
> Project: Isis
> Issue Type: New Feature
> Components: Core, Core: Viewer: Wicket
> Affects Versions: viewer-wicket-1.7.0
> Reporter: Dan Haywood
> Assignee: Dan Haywood
> Fix For: 1.12.0
>
>
> 4-jan-2016:
> Divide the screen into two halves.
> All properties in separate tabs.
> Each collection in its own tabs.
> ~~~
> as per [1] mailing list thread.
> The example in the mailng list splits up the object's properties/collections
> (contributed or otherwise) into two different sets of tabs... but as a first
> pass I think a single row of tabs ought to suffice.
> We also need to be mindful that we may want to use tabs as a metaphor for
> multiple opened objects (as a replacement for bookmarks), so this is another
> reason for a single row of tabs.
> To support this would require extensions to @DomainObjectLayout or equivalent
> xxx.layout.json file.
> [1] http://markmail.org/message/merftvqoiy6ht3kq
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
