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
