Hi Marius, We need trees: * for global vision/management: (AllDocs) doing crud operations on pages in particular (but would be nice also to rename/move/delete spaces/wikis? ) * for navigation: in a panel that should list parent/child relation or space/page relation for the current page/space. * for selection: especially when doing import or multi-page exports * for development: as you said a full XWiki Entity Tree would be nice for applications like AWM, but we would need also partial Entity Trees for Class or Objects Editor (displaying objects and properties) * for classification: any category/sub-category or folder/page type of classification would need a tree (Blog Categories, File Manager, etc. ... tags, photo albums, etc.) when the structure is user/defined based on a parent/child relation
Things to consider: * multiple views: wiki/space/page vs. parent/child * multiple parent: simple parent vs. multiple parent classification (maybe in case of tags, photo albums) Wishes: * Normal: ** I would like that we could use a consistent tree across XWiki functionality. ** I wish we could have operations on tree entries (by drag&drop or just from actions). * Ideas: ** I wish users could define their own tree structures (not necessarily having XWiki's two dimensions [parent/child and location] but maybe defining a custom structure: example, I'm writing a book and I want to organize the pages in chapters. Maybe I have some pages that I don't know exactly in what chapter to put [orphan/hanging] or that could go in multiple chapters ) ** Change the display of a tree from vertical to horizontal (like a graph) (could work for the book example) Lacking: * Normal: ** Navigation panel (when visualizing a space or even a wiki we could display a contextual {{spaces/}} gadget in a panel that could be expanded) ** Documentation panel (of related pages displaying the parent/child relationship) ** Multi-page export with entity selection ** Groups/Users * Ideas: ** Dependencies Tree for applications installed with EM ** Roles/Rights vs. Inherited/Global/Locally set Rights Tree (kind of crazy I know :) ) ** Major / Minor versions history Not sure exactly what you expected people to answer :) I tried to think of all kinds of usages (not all are needed or realistic). Hope it helps. Thanks, Caty On Thu, Sep 25, 2014 at 4:56 PM, Dmitry Bakbardin <haru_mamb...@mail.ru> wrote: > > Hi, Marius! > I would add also > wiki > space > page > [anchor in a page] > in the WYSIWYG editor. > + one more vote for: > 1. wiki > space > page > [translations | attachments | objects | > classProperties] > object > objectProperties > 2. parent page > child page > I'm almost happy with this macro: > http://extensions.xwiki.org/xwiki/bin/view/Extension/HierarchyMacro > It has very important feature: EDITABLE tree - one can change order of > pages in the tree and page's parent by moving it "up or down". > I'm using it now as a "TOC" of space. This macro has few critical bugs, > e.g. http://jira.xwiki.org/browse/HIERARCHYM-5 > Also I'd be completely happy to have an option "Blacklisted pages list" in > each and every tree/macro. > > > Kind regards, > > Dmitry > > > Thu, 25 Sep 2014 16:04:57 +0300 от Marius Dumitru Florea < > mariusdumitru.flo...@xwiki.com>: > >Hi guys, > > > >There are a couple of places in XWiki where we use trees to display > >structured / hierarchical data. Are trees a good solution for data > >visualization in those cases? Can those trees be improved? Are there > >other places in XWiki where you would like to see a tree? > > > >Let me review some of the trees we currently have: > > > >1. Document Index Tree > > > >wiki > space > page > [attachments | page] > > > >This tree is also used in the WYSIWYG editor when you create a link to > >a wiki page or to an attachment. It shows the spaces on the first > >level and then under each space the parent-child hierarchy of > >documents from that space. If a document has attachments then a > >special child node is added. The tree can also display wikis on the > >first level and then spaces on the second. > > > >So it mixes two hierarchies: wiki > space > page > attachment and > >parent > child. This can be confusing. For instance Blog.WebHome has > >Main.WebHome as parent, but you don't see Blog.WebHome under the > >Main.WebHome node in the tree because it is in a different space. > > > >2. XAR Import > > > >space > page > > > >This is a very simple tree with only two levels. I don't have any > >problem with it. Would be cool if it would show more information, like > >attachments or objects, but it's a bit more complex to get this kind > >of data from the XAR without reading the documents first. > > > >3. Dynamic Hierarchy Macro ( > > > http://extensions.xwiki.org/xwiki/bin/view/Extension/Dynamic+Hierarchy+Macro > >) > > > >parent page > child page > > > >Unlike the Document Index Tree, this tree uses only the parent-child > >hierarchy. You don't see the spaces but at least you get the full > >parent-child hierarchy. This time Blog.WebHome is a child of the > >Main.WebHome node. > > > >I'm not sure it's better than the Document Index Tree, at least not on > >the default XWiki documents, maybe because the document titles and the > >way we set the parent in the default distribution is not very > >consistent. > > > >---------- > > > >WDYT about these trees? > > > >As a developer, I would love to see a full XWiki Entity Tree: > > > >wiki > space > page > [translations | attachments | objects | > >classProperties] > object > objectProperties > > > >As in http://imgur.com/q0br8xT . > > > >As a user, I don't know. You tell me :) > > > >Thanks, > >Marius > >_______________________________________________ > >users mailing list > >users@xwiki.org > >http://lists.xwiki.org/mailman/listinfo/users > > _______________________________________________ > users mailing list > users@xwiki.org > http://lists.xwiki.org/mailman/listinfo/users > _______________________________________________ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users