On Fri, Sep 26, 2014 at 1:09 PM, Denis Gervalle <[email protected]> wrote: > On Fri, Sep 26, 2014 at 11:01 AM, Marius Dumitru Florea < > [email protected]> wrote: > >> Hi Denis, >> >> On Fri, Sep 26, 2014 at 10:23 AM, Denis Gervalle <[email protected]> wrote: >> > Hi Marius, >> > >> >> > Have you also tried other solution ? >> >> It depends what you understand by "tried". I have *investigated* other >> solutions of course, not all of them obviously. I've chosen jsTree for >> the File Manager and I didn't have any issues. >> >
> Would be curious to know more about your experience and why you finally > choose to use jsTree ? Initially I searched for a tree based on AngularJS. I couldn't fine one good enough so I searched for a jQuery tree. > Actually, it seems really because it is the most popular, and it has work > on existing project. Yes, the two main reasons were: popularity and the fact that some people I know have used it already in production (Dynamic Hierarchy Tree). > These could be good argument, I agree, it could be reinforced by more > technical ones. Another reason I chose jsTree is because it has a plugin that offers a context menu and I needed this for the File Manager. As I said, I had a good experience with jsTree while working on the File Manager. The documentation is good. The API is quite easy to use. I prefer camelcase instead of the "_" (underscore) notation they use (as in "select_node") but otherwise I have nothing to complain. > > >> >> > , and from the popular I know, >> > FancyTree (successor of DynaTree) https://github.com/mar10/fancytree/ >> look >> > like a good candidate ? >> >> Yes, it does look like a good tree, but I haven't used it so I can't >> tell how it works in a real project, beyond a simple demo. >> >> The first "issue" I've seen is that the documentation is not very >> clean on how you can control the node icon from the data source. This >> http://wwwendt.de/tech/fancytree/doc/jsdoc/global.html#NodeData >> doesn't include an "icon" property, but I've seen: >> >> // Append a new child node >> activeNode.addChildren({ >> title: "Document using a custom icon", >> icon: "customdoc1.gif" >> }); >> > > According to the documentation, other properties are copied to node.data, > isn't it what happen for icon ? > I agree, this looks strange. > > >> on https://github.com/mar10/fancytree/wiki#api-access (putting aside >> the fact that "children" is plural so I would expect to receive an >> array not a map). >> > > http://wwwendt.de/tech/fancytree/doc/jsdoc/FancytreeNode.html#addChildren > It is actually an array, they probably support the non-array case for > simplicity. > > >> > Its community looks comparable but it is a bit less popular. >> >> > Demonstrated features are equivalent and potentially better >> >> Can you tell me what features of FancyTree that are missing from >> jsTree are important for us in XWiki or for applications written on >> top of XWiki? >> > > I just said that from their site, they seems to have more extended > features, maybe they have the same. > > >> >> > (my feeling with the demo of >> > jsTree was bad, could be the demo settings however). >> >> Can you give us more details?.. What was bad? What didn't work? >> > > This was just my feeling, using both demo, not really valuable, I just > mention it to minimize the previous argument. > > >> >> > But, more importantly, its browser support seems to be taken more >> > seriously. >> >> > I have seen couple of issue, event recently with IE support in >> > JsTree, >> >> Can you give us some examples? At least to understand if those issues >> are important for us in XWiki. Also, have you tried to report those >> issues to jsTree? Are you sure the jsTree community is not willing to >> fix those issues? >> > > I have simply done some googling on "jsTree IE issues" and similar, with > some date limit, to be surprise to see recent report about basic feature > completely broken. These have surely been fixed, but it was surprising they > get out. Added their wording, I have the feeling that the maintainer is > like me, not really a microsoft fan. I am afraid that he fix more than he > test, seeing the issues reported. > It does not support IE 7 also. Doesn't we still support it ? We currently support only IE8+ (see http://dev.xwiki.org/xwiki/bin/view/Community/BrowserSupportStrategy ) and (I hope) we're going to drop IE8 and IE9 soon. So I don't think there's a problem here. > > >> >> > like if IE was just tested at the end, and their support moto "All >> > modern browsers are supported, as well as IE8" is not really engaging. >> The >> > compatibility of FancyTree see far better for IE (IE from 6 to 11). >> >> Are you saying this from your experience with FancyTree or just by >> reading the documentation? > > > From the documentation, this should be tested, I agree. But when you write > explicitely your support for IE6, you seems really more concerned than when > you write "as well as IE8" ! As I said, we don't support IE6/7, and we're close enough to drop support for IE8. > > On extensions.xwiki.org there are currently >> 3 extensions that use jsTree and none that use FancyTree. Among those >> that use jsTree there is Dynamic Hierarchy Tree which is used, AFAIK, >> on production on some XWiki installations. I'm not aware of IE issues >> there with jsTree, but I'll double check. >> > > This is a good argument in favor of jsTree. > > >> >> > Since, >> > we have not finished our discussion regarding IE support, I am not >> > confortable with JsTree if we continue support for IE < 9. >> >> Again, if you don't mention exactly what IE issues you have >> encountered with jsTree, then I feel that your worries are not really >> justified. >> > > My worries are only based on previous feedback read on the net. > If with the experience you have, you are confident this is not an issue, > let's go for it. I've used it on the File Manager only. I'll ask some people that have used the Dynamic Hierarchy Macro to see if they had any issues. Maybe they had other use cases than what I had on the File Manager. > > >> >> > At least, it >> > would be good to compare these two and have other arguments then >> popularity >> > to choose JsTree IMO. >> >> Popularity is very important. >> > > It is, but I dislike monopoly based on popularity. There tons of popular > crap, and much more good unknown stuffs. > If you base your choice on popularity, you never choose XWiki :) > > >> >> Thanks, >> Marius >> >> > >> > Regards, >> > >> > On Thu, Sep 25, 2014 at 12:11 PM, Marius Dumitru Florea < >> > [email protected]> wrote: >> > >> >> Hi devs, >> >> >> >> There are a couple of places in XWiki were a tree widget is used or >> >> needed: document index, WYSIWYG editor wiki page linking, XAR import, >> >> navigation panel, database tree list, report step of Distribution >> >> Wizard, extension upgrade when asking confirmation to clean unused >> >> pages, etc. But we don't have a standard / recommended tree widget / >> >> library. We use either SmartClient which is very heavy or a custom >> >> tree based on Prototype.js. >> >> >> >> Since we want to ditch the heavy SmartClient tree and we decided to >> >> move away from the dead Prototype.js to jQuery I propose to use jsTree >> >> ( http://www.jstree.com/ ) as the standard / recommended library for >> >> creating trees in XWiki. >> >> >> >> It is one of the best and most used tree widgets written using jQuery. >> >> I have used jsTree on the File Manager ( >> >> >> >> >> http://extensions.xwiki.org/xwiki/bin/view/Extension/File+Manager+Application >> >> ) and it was a positive experience. Moreover, there are other >> >> extensions based on, like the Dynamic Hierarchy Macro ( >> >> >> >> >> http://extensions.xwiki.org/xwiki/bin/view/Extension/Dynamic+Hierarchy+Macro >> >> ). >> >> >> >> My plan is: >> >> * include jsTree in the default distribution (through a webjar >> >> dependency); it won't be loaded by default, obviously; you'll have to >> >> use Require.js to load it. >> >> * start rewriting the current trees using jsTree >> >> >> >> Here's my +1. >> >> >> >> Thanks, >> >> Marius >> >> _______________________________________________ >> >> devs mailing list >> >> [email protected] >> >> http://lists.xwiki.org/mailman/listinfo/devs >> >> >> > >> > >> > >> > -- >> > Denis Gervalle >> > SOFTEC sa - CEO >> > _______________________________________________ >> > devs mailing list >> > [email protected] >> > http://lists.xwiki.org/mailman/listinfo/devs >> _______________________________________________ >> devs mailing list >> [email protected] >> http://lists.xwiki.org/mailman/listinfo/devs >> > > > > -- > Denis Gervalle > SOFTEC sa - CEO > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
