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.

(line 4) 404 at this url
(line 5) this is not the right url for this plugin's documentation
(line 12) should mention that this plugin depends on ui.core.js
(line 18) use .disableSelection() from UI Core instead
(lines 19-20, 35, 36, 63-64, 69-70, 77-78, 85-86, 106, 107) curly braces should be used
(line 29) action is not a valid attribute for the A element (see http://www.w3.org/TR/html401/struct/links.html#edef-A). Recommend using a data attribute or metadata in the class attribute and triggering a custom 'select' or 'selected' event when a node is selected. Then the plugin user can handle the node selection based on the metadata on the item.
(line 30) it would be nice if nodes could contain hyperlinks, for navigation. This return false is preventing that.
(line 34) no need to check if event.target is LI since you bound the click event to the LI
(lines 38-39, 47-48, 122-125, 131-134) Code duplication. Suggest refactor
(lines 39, 48, 63, 77, 124, 133) "close" should be "closed" to match "open"
(line 56) $("<ul>"); should be written with a closing tag $("<ul></ul>");
(line 62) $("<li>") should be written with a closing tag $("<li></li>")
(lines 62, 76) I recommend against using lowercase L ( l ) as a variable name as it can too easily be mistaken for a numeral 1 or a capital I or a pipe | depending on the font used.
(lines 62-70, 76-86) $(node) should be cached in a variable

(lines 61-71, 75-87) almost all this code is duplicated. Suggest refactor
(line 91) _getData() , if defined, should be an override of UI widget's _getData which returns plugin option values based on key. It's rare that's ever even needed. You should pick a different name for this function
(line 108) nodo is undefined if both the previous ifs were false. What if type is not one of 'html' 'json' 'xml'?
(line 115-117) it would be nice if the user of the plugin could handle this error, instead of having an alert hard-coded. Use a custom event.
(lines 138-140) what is the need for this method? Why not just call $('#myTree').find('li').length ?
(line 142) $.widget.prototype.apply(this, arguments); should be $.widget.prototype.destroy.apply(this, arguments);
(line 143) the destroy method for this widget is not implemented. Should return original element as closely as possible back to its pre-init state, such as unbinding events
Why attr("clase") and node.clase instead of attr("class") and node['class']?
All css classnames should be prefixed, such as shtree-selected, shtree-open, shtree-closed
No jQuery UI CSS Framework classes have been used

If _getData() is getting data, why is it using the POST method? Also, why is async set to false? This will block the browser UI.
The value of using ajax to load a tree is that the whole tree does not need to be loaded up-front. In the examples you've shown, all the trees are loaded completely up-front, and synchrounously. It seems there's no way to get the data for a single collapsed node via ajax when it is expanded.
There is no implemented _setData() common to jQuery UI widgets, meaning option values get changed after initialization with no effect.
There is no implemented enable and disable methods common to jQuery UI widgets, meaning those methods will get called with no effect.
Why are collapseAll and expandAll defined as getters? Any reason these can't be chainable, as they don't return a useful value?
I recommend having options to specify how to find node parents (UL), node children (LI), and node items (A) instead of hard-coding throughout. This will
- make it more readable
- make it more configurable
- ensure you're not removing classes too aggressively from elements you shouldn't, such as self.element.find("a").removeClass("selected")

There is no visual indicator of keyboard focus
There doesn't seem to be a way to expand/collapse a node using the keyboard, only select one.
Overall, this is not yet a widget, it's a plugin. While I don't want to discourage you from using the jQuery UI widget factory, you haven't used it yet, beyond init and defaults setting init options. No options can be changed after init, there are no custom events, enable and disable are not implemented, destroy does nothing, there are no widget-specific classes, and there are no css framework classes.
A few things I would love to see
- full keyboard support
- separate A elements for expand/collapse and node selection
- full use of jQuery UI CSS Framework classes and icons
- clear plugin-specific classes identifying node parents, node children, node items, node states
- a way to have metadata for each node be persisted from json->html, xml->html
- a way to handle node selection
- dynamic loading of node data via ajax when a collapsed node is expanded

my respect, is a masterpiece.