[xwiki-users] [Discussion] What trees would you like to see in the XWiki garden?
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
On Thu, Sep 25, 2014 at 3:04 PM, Marius Dumitru Florea <[email protected]> wrote:
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.
Actually we do read the documents to get the data we have right now but those data are at the beginning of the XML and we stop reading as soon as we got them.
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 [email protected] http://lists.xwiki.org/mailman/listinfo/users
-- Thomas Mortagne
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 <[email protected]>:
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 [email protected] http://lists.xwiki.org/mailman/listinfo/users
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 <[email protected]> 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 < [email protected]>:
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 [email protected] http://lists.xwiki.org/mailman/listinfo/users
_______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users
Hi Caty, On Mon, Sep 29, 2014 at 3:34 PM, Ecaterina Moraru (Valica) <[email protected]> wrote:
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.
That is the plan.
** I wish we could have operations on tree entries (by drag&drop or just from actions).
We'll have drag & drop and context menu (which could be opened with a tap of a button on mobile / small screens).
* 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 )
I'm currently writing a generic tree widget based on jsTree that will behave much like the live table: you define your tree structure in a wiki page (similar to the live table results page) and then you specify this page in the tree configuration. So you can use whatever tree structure your want.
** Change the display of a tree from vertical to horizontal (like a graph) (could work for the book example)
I don't understand what you mean. Can you give me an 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.
It helps, thanks! The main reason I started this thread is because I'm going to rewrite some of the trees and I wasn't sure whether I should keep the current structure and behaviour or if you think there is room for improvements. Since none one complained about the structure of the current tress (the AllDocs tree for instance) then I guess I'll simply rewrite them using jsTree. Thanks, Marius
Thanks, Caty
On Thu, Sep 25, 2014 at 4:56 PM, Dmitry Bakbardin <[email protected]> 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 < [email protected]>:
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 [email protected] http://lists.xwiki.org/mailman/listinfo/users
_______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users
_______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users
Hi, As I started investigating on Hierarchy Macro and Dynamic Hierarchy Macro (after reading this thread), I have some feedbacks that I didn't find in the list of JIRA issues. They mostly relate to trying to display a tree of a whole wiki structure: - "excludes": it would be nice to allow patterns here. Usually I don't want to filter out a space (though it can be useful), or a list of pages full names, but I want to exclude "*.WebPreferences" for example. Maybe with issue of not showing hidden documents, the need for this is not important. - "onlyroots": maybe something similar to the {{toc/}} macro param "depth" would be even more useful (and you would set "depth=1" for an equivalent to "onlyroots") - "displayvalue": really only nice-to-have, but instead of choosing a value one could like to specify a pattern, for example "${displayTitle} (${fullName})" - if you choose "displayvalue=displayTitle", and a document has an empty title, it shows an empty entry. Could be nice to fall back to doc.fullName for example in this case. Same for "displayvalue=title" I suppose. - "defaultparent": if it's highly recommended to set a value when tree is editable, I would either set a default value (like "Main.WebHome"), either refuse to drop documents at root if not set (or display a warning "you are about to create an orphan") - the Dynamic hierarchy macro scales better than the Hierarchy macro, but still there's an issue if there are too many entries at one level, which in my case prevents really using it at wiki scope or as a "space panel" as I have several spaces with many documents. If it's in a panel and you land on one of those spaces, the panel will never show up, and it will eat many resources server-side to not display anything at the end. Would be nice to introduce something similar to the solr facets, ie if there are too many items at a level load the first 10, and clicking on "..." loads next 10, etc (or have a configurable "maxitemsperlevel" param instead of 10). If you feel some JIRAs would be interesting out of these, tell me and I can create them, BR, Jeremie 2014-09-25 15:56 GMT+02:00 Dmitry Bakbardin <[email protected]>:
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 < [email protected]>:
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 [email protected] http://lists.xwiki.org/mailman/listinfo/users
_______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users
On Tue, Sep 30, 2014 at 12:36 PM, Jeremie BOUSQUET <[email protected]> wrote:
Hi,
As I started investigating on Hierarchy Macro and Dynamic Hierarchy Macro (after reading this thread), I have some feedbacks that I didn't find in the list of JIRA issues. They mostly relate to trying to display a tree of a whole wiki structure: - "excludes": it would be nice to allow patterns here. Usually I don't want to filter out a space (though it can be useful), or a list of pages full names, but I want to exclude "*.WebPreferences" for example. Maybe with issue of not showing hidden documents, the need for this is not important. - "onlyroots": maybe something similar to the {{toc/}} macro param "depth" would be even more useful (and you would set "depth=1" for an equivalent to "onlyroots") - "displayvalue": really only nice-to-have, but instead of choosing a value one could like to specify a pattern, for example "${displayTitle} (${fullName})" - if you choose "displayvalue=displayTitle", and a document has an empty title, it shows an empty entry. Could be nice to fall back to doc.fullName for example in this case. Same for "displayvalue=title" I suppose. - "defaultparent": if it's highly recommended to set a value when tree is editable, I would either set a default value (like "Main.WebHome"), either refuse to drop documents at root if not set (or display a warning "you are about to create an orphan")
- the Dynamic hierarchy macro scales better than the Hierarchy macro, but still there's an issue if there are too many entries at one level, which in my case prevents really using it at wiki scope or as a "space panel" as I have several spaces with many documents. If it's in a panel and you land on one of those spaces, the panel will never show up, and it will eat many resources server-side to not display anything at the end. Would be nice to introduce something similar to the solr facets, ie if there are too many items at a level load the first 10, and clicking on "..." loads next 10, etc (or have a configurable "maxitemsperlevel" param instead of 10).
I've already implemented this in the jsTree-based tree widget I'm working on. I'm gong to modify the Dynamic Hierarchy Macro to use it.
If you feel some JIRAs would be interesting out of these, tell me and I can create them,
Most of this is related to the Dynamic Hierarchy Macro so you can report it in the corresponding JIRA project (if there is one). Thanks for the feedback, Marius
BR, Jeremie
2014-09-25 15:56 GMT+02:00 Dmitry Bakbardin <[email protected]>:
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 < [email protected]>:
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 [email protected] http://lists.xwiki.org/mailman/listinfo/users
_______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users
_______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users
participants (5)
-
Dmitry Bakbardin -
Ecaterina Moraru (Valica) -
Jeremie BOUSQUET -
Marius Dumitru Florea -
Thomas Mortagne