I'll try to start using and testing it soon, so new thoughts will be reported.

By the way, speaking on "closed" state I've recently discussed with you @code.google.com: I've found these lines in the docs:
// Properties below are only used for NON-leaf nodes
state: "closed", // or "open"
Please, tell me how to specify that the node possibly has children that are not yet loaded - not using jsTree's default ajax ability?

The other thought I've remembered by now is about .lock method: the lock should only block _user_ interactions (that come from mouse and keyboard) and not API calls. Locking everything made me set up my own lock flag and check it in the event handlers (I must add new nodes while the tree is locked).

P.S. Please, make the code fragments on the jsTree site scrollable horizontally as they aren't fully readable ( overflow-x: auto or scroll ).

One more question: are there any DOM events triggered on tree container (via .trigger jQuery method)? If not, you should consider reviewing jQuery UI core _trigger function and how the widgets are using it. The function calls the corresponding callback _and_ triggers an event on container element. That would be useful to have a list of bound events (atttached with .bind('jsTreecallbackname', ...)) instead of defining a single function during initialization procedure.

More thoughts... Mark the functions that are strictly not intended for public use as private by using an underscore ( '_' ) prefix - that is a jQuery UI widget guideline. This will help you to build a jQuery UI widget out of your jQuery plugin faster and will help users not to mix the things up.

@sompylasar This Google Code page doesn't seem to have any code or demos to view. Is there a direct link to a demo and/or documentation?

Methods:
* nodeAttr - Sets or gets node attributes. Predefined attributes: text,rel,href,title,disabledTitle,cache,hascached,remote,collapsed,expanded,enabled,disabled,selected,error.
* nodeContext - Constructs an object that describes node's current state.
* setChildNodes - Creates a collection of nodes and adds/replaces child nodes of the specified node.
* insertNode - Inserts one or more nodes into arbitary position in the tree (available options: prepend,append,after,before).
* removeNode - Removes one or more nodes from the tree.
* getNode - Finds closest tree node element from any child element or the node itself.
* getParentNode - Finds parent node of given node.
* expandNode - Expands one or more nodes. Allows to set how deep to expand (recursively).
* collapseNode - Collapses one or more nodes. Cancels pending node children requests.
* toggleNode - Toggles one or more nodes between expanded and collapsed state.
* selectNode - Selects one or more nodes. Multiselect is controlled by method argument.
* deselectNode - Deselects one or more nodes.
* enableNode - Enables one or more nodes.
* disableNode - Disables one or more nodes.
* hideNode - Hides one or more nodes.
* showNode - Shows one or more nodes.

Events (eventtypes are self-documenting):
* node-before-insert (cancellable)
* node-inserted
* node-before-remove (cancellable)
* node-removed
* node-before-expand (cancellable)
* node-expanded
* node-before-collapse (cancellable)
* node-collapsed
* node-before-load (cancellable)
* node-load-started
* node-load-success
* node-load-error
* node-load-complete
* node-click
* node-before-select (cancellable)
* node-selected
* node-before-deselect (cancellable)
* node-deselected
* node-before-enable (cancellable)
* node-enabled
* node-before-disable (cancellable)
* node-disabled
* node-before-hide (cancellable)
* node-hidden
* node-before-show (cancellable)
* node-shown

Extra features:
* templates for localized strings
* templates for generated ids
* templates for async request parameters

These were already implemented features. Of course, they need some testing, but the code is well-structured so it should not be a problem.

I think what you have makes sense now that you've explained it. You would need two separate containers so place the icon and texture background images so that's reasonable.

That is a new way of thinking for me, really... But it makes sense. I'm starting to look at UI widgets from another point of view.

The one thing that comes along is that there is a lack of events on jQuery DOM manipulations. For example, we can't track CSS class change to invoke a state change event. The only event we can use is 'remove' (and you can see, I'm using it in the tree to track node removal anyways - both from the API and from jQuery DOM manip).

My project was started exactly to provide extensive events-driven component (I need it at my job). I might be using wrong instrument by choosing jQuery UI... but now I'm unable to change my way to something different.

I agree on Checkbox and Selectable - these may be somehow utilized by the tree. Of course, the same for Draggable and Droppable. But I think the add/remove logic of nodes, quite complex logic of downloading the nodes, tracking of network errors, should be in the tree, or we are loosing events capabilities. I see widget factory also goes towards having both callbacks and events, not just callbacks as most of other jQuery plugins still have.

Lightweight is good for some cases, but other ones need full control, which most of current plugins cannot (or don't want to) provide. Anyways, I can contribute to a lightweight version, though having a sophisticated one for my job.

Comments?

Generally, I thought jQuery UI is being built ontop of jQuery itself, not nearby. Already existing widgets are for sure catching DOM events and presenting their own events - they use jQuery as a tool to get it cross-browser and convenient. The same should apply to a widget API. Why not redefine 'append' if it gets us onto a new level (e.g. adds some events triggering and JSON/HTML conversion)? The client code is working with data, not its representation as a bunch of HTML elements - that's what the User Interface framework should provide.

Please, don't beat me, that was an expression of my humble opinion.

I agree we should reuse existing code (as I've already done in my Ribbon widget - thanks to Tabs). But working with a widget means working with it's API that is a higher level than just DOM manip. Inserting a node into a tree is not just appending a 'li' to an 'ul' - it's tracking parent node state and changing it properly, tracking possible rules of what can be added into tree and what cannot, etc.

I also agree that I should have reused $.data and $.metadata instead of writing my own 'nodeAttr' implementation. But that doesn't mean _client code_ should be using $.data itself - it will use 'nodeAttr' API of the tree widget and it should not know how it is implemented internally. The only thing the client code knows that it will get an attribute attached to a tree node, whether the node will be moving along the tree or temporarly be removed during a drag'n'drop operation.

I've studied your technique and pointed out that it's leading to non-consistent behavior that can be avoided (I think floating last element to crop the dots by shortening the element height is not right).

If merging all the states into one sprite is OK, I can do that. We'll have one element for tree structure dots ( ul ), one for node handle state with corresponding dots glued together ( li ), other for node background ( a ) and the last one for the text and icon ( span ). That looks fine for me.

P.S. In my opinion, the DOM after JS applied doesn't have to be so semantic as the initial markup. Before CSS[n] that will allow us to set multiple backgrounds appears, we have to use non-semantic DOM elements to mimic overlays... And if we decided not to use <img> for icons, we have to use some other element, e.g. span with another classname attached.

Regards.

By the way, maybe we should try to get the dots as borders of some element? This will give us flexibility of colors and style though having the correct rendering in any sizes and line heights.