I know there is so much alternative for tree in HTML/JS, but the simplest way is to improve tree directly when you have already use it. If the XUL is truly dead, then mozilla community should consider to remove it totally from the codebase, but not reject to improve it.
在 2014年10月14日星期二UTC+8上午11时11分39秒，somb...@gmail.com写道： > On 10/13/2014 07:06 PM, Joshua Cranmer 🐧 wrote: > > > I nominally agree with this sentiment, but there are a few caveats: > > > 1. nsITreeView and <xul:tree> exist and are usable in Mozilla code > > > today. No HTML-based alternative to these are so easily usable. > > > > There are many lazy-rendering infinite tree/table/infinite list > > implementations out there: > > > > For example: > > - Dojo: TreeGrind/LazyTreeGrid > > http://dojotoolkit.org/reference-guide/1.10/dojox/grid/TreeGrid.html > > - dgrid (Dojo related): http://dojofoundation.org/packages/dgrid/ > > - tree examples > > - column hider extension: > > https://github.com/SitePen/dgrid/blob/v0.3.15/doc/components/extensions/ColumnHider.md > > - the things that the dgrid website provides in its comparison table > > - Sencha (which is GPLv3 but has a weird library style exception it > > seems): http://dev.sencha.com/ext/5.0.1/examples/tree/locking-treegrid.html > > - React (just a list, but an example of how easy such a component is in > > React): https://github.com/orgsync/react-list > > > > > 2. The main rationale for this feature (bug 213945, although I doubt > > > the approach currently taken in bug 441414 is actually usable for that > > > anyways) involves a tree view that is currently performance-sensitive > > > and comprises 13,446 lines of C++ code, so it can't easily move to JS. > > > Which means some sort of XPIDL API is going to be necessary anyways, > > > and that API would probably look vaguely similar to nsITreeView. > > > > The performance-sensitive parts of the XUL tree view widget is that it > > paints synchronously and does not do any smart caching on its own. > > These are deficiencies of the C++ XUL tree implementation that an HTML > > implementation need not share. (In fact, I've never seen any that would > > have the same performance problems; you'd have to write your own widget > > from the ground up in Canvas to reproduce them.) > > > > For the bug 213945 Thunderbird use-case, the existing C++ nsITreeView > > interface implemented by the mailnews DBView could easily be used by a > > Dojo Store adapter/etc. Any calls made by C++ code to update the tree > > view can (and already do) call JS code to cause proper invalidation of > > the JS/HTML-exposed data-model. I say this as someone with expensive > > experience working with that area of the Thunderbird codebase and who > > considered our options and decided that an HTML-based widget was the way > > to go. > > > > > 3. I've never done a lot of UI coding myself, so I don't know if my > > > recollection is correct anymore or even if it ever was, but I recall > > > hearing that XUL and HTML didn't get together terribly well. > > > > > > So if we had an HTML tree implementation that: > > > a) supported lazy generation of row data > > > b) supported column pickers, rearrangeable columns, etc. > > > c) supported CSS queries similar to what <xul:tree> does already, > > > > The examples I give above I believe all support these features. > > > > > d) could be used or made usable from C++ without too much effort > > > > As noted above, I don't think Thunderbird's use-case actually requires > > C++ code to meaningfully interact with the tree widget in a way that > > can't be compensated for in JS. > > > > > e) already existed and were generally maintained in toolkit/ > > > > This is a weird, NIH-ish requirement. Why should Mozilla create and > > maintain an HTML tree widget when there are so many open source > > implementations that already exist? > > > > > f) were properly accessible > > > > A good concern and something that should be used for evaluation of any > > library options. Since the widgets above all use the HTML DOM, it's a > > question of making sure they are using the appropriate HTML and ARIA > > attributes (ex: aria-posinset). > > > > Andrew _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
