What one can learn about dhtmlxTreeGrid after using it for a couple of weeks? This evaluation version feedback is likely to save your “couple of weeks” or at least it could be of interest for those who consider using this component…
There were a few things we were looking for at the onset of our evaluation (in their order of importance):
1) Performance
The performance was spectacular. Our company actually has a similar solution in-place which utilized HTC files to create tree-grid structures out of <table> elements based on XML streams. We had found that, while it met all requirements, it did so at a heavy cost in performance. We knew that it’s performance could be dramatically improved were we to re-work the DOM structure involved, however due to time constraints we decided to perform an evaluation of your product before beginning such a project. I’m glad we did. The numbers we captured speak for themselves, so I’ll just provide a sample of those:
Nodes Original Time New Time % improvement 1 6.72s .29s 2317% 10 7.08 .34 2095% 100 11.33 .37 3062% 10,000 (timed out) 1.03 OMG! The above numbers were captured with the “smartXML” enabled, so I see no reason why the performance gains will not scale higher should we ever need it to (10,000 is our current expected upper-limit.) When all is totaled up, we saw an average performance improvement of nearly 3000%. Everyone (myself included) was much impressed.
2) Functionality
Our tree-grid utilized the tree itself (image and , checkboxes for most (but not all) rows and a “date” column. Sorting of the date column was required for both ASC and DESC, while the tree should only be sort-able via ASC. A third column would be displayed in certain situations which would be a custom column type (If “0” is in the field, display one image, if “1” display a different image, etc.) For all of the above, we had no problems once we figured out how each different requirement may be met (see “5) Support” below.) One thing which we would have liked was a finer-grain control over the grid lines.
Our current solution utilizes grid lines to differentiate the relationship between two different kinds of child nodes – email attachments are connected to their parent via lines while email replies are merely indented, for example. We worked around this (seeming?) limitation by placing all the attachments into a sub-node labeled “Attachments” (yeah; we went outside the box for that label…) Aside from that one functional change, the results look and act close enough as to make no difference and we are well satisfied that any further functional needs we have will be met with minimal effort.
Our evaluation also spanned into the area of the non-tree grid offering. It just so happened that a requirement came through the pipe during our evaluation which matched the “filter” functionality. When we showed the samples to our product management team, the response was one of excitement. The “grouping” functionality was something which we also displayed, to an equally positive reception.
3) Stability
Aside from improper configuration issues, I’ve not seen anything which would raise any concerns regarding the stability of the DHTMLx suite of offerings. Based on your current client list, this was not much of a surprise. Bravo.
4a) Ease of implementation and 4b) Support
The main reason why our company implemented an HTC solution in the first place was to allow for easy implementation and customization without having to re-code everything each time. In other words, it needed to work without being a headache.
“Ease of implementation” and “Support” are on the same level for me, really. If the solution is easy to use then I won’t need much help. If it’s not, then help should be readily available. “Help”, in this case, is represented by both documentation and query response times.
The DHTMLx suite (or the parts of it we evaluated, at least) is about as easy to implement as I could imagine such a robust system could be. When we wanted a simple implementation, we got one with a minimal investment of time and effort. The more complex solutions required a larger investment, but most of that was due to discovering how to do what we needed to do. Once we figured that out, things worked as expected and desired – usually on the first try.
Figuring out how to do the various things we wanted to do was the most difficult part of the evaluation. The documentation (both supplied in the evaluation and online) was nominally complete (in that all functionality is mentioned somewhere), it just isn’t easy to understand. Most sections feel incomplete – often lacking example code (examples often existed, just not in the documentation itself) or any real explanations (it was more like, “this is possible” than “this is how you do this.”) As I began to understand the library better, the documentation made more sense. But by then I was referring to it less frequently and so that benefit was rather minimal. It would be nice to have the documentation written for the “noob” audience instead of the experienced one.
Twice during our evaluation, we submitted questions to the Knowledge Base. Both times the response was prompt (<24hrs) and resolved the question asked. This was a very pleasant surprise and made our woes with the documentation significantly less of an issue.
Were I asked to rate the DHTMLx library, I would give it a 9/10. I would certainly recommend it as a “must-have” solution for any enterprise-class web application. The savings in time and effort are only dwarfed when compared against the performance gains.
D. Hutchings
Senior UI Engineer
CaseCentral, Inc.