On Tue, Sep 30, 2014 at 12:36 PM, Jeremie BOUSQUET
<jeremie.bousq...@gmail.com> 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 <haru_mamb...@mail.ru>: > >> >> 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 _______________________________________________ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
