FEATURE SUGGESTIONS

[vakata]

I decided to ask you guys on how you would like jsTree to evolve - so
in this thread I will post some of the changes I have planned - if you
disagree/agree - let me know. I really need your opinion!

1) How about instead of numerous arguments in each callback, to have a
single object passed to every callback with some properties. For
example the onmove callback will receive a single "data" object in the
form:
{
node : ...,
ref_node : ...,
move_type : ...,
rollback : ...,
tree_reference : ...
}
This will help for easier migration from version to version, because
your code will not be dependent on the number and order of arguments,
and if a new argument is requested it will not break older code.

2) How do you feel about calling all the callbacks in the tree
reference scope? So that instead of TREE_OBJ.func(); you would do
"this.func()". I believe this will be a small change but will make the
tree more consistent.

3) API functions - as pointed out by quite a few of you all the tree
functions are user centric. Meaning for example when calling create on
a closed node, the node is first opened, the contents displayed, then
a node is created and put into rename mode. Every developer on the
other hand would like to have the ability to silently create a node.
I have two ideas about this one, neither of them very elegant - if
anyone has a better solution - go ahead!
IDEA 1: have an argument in each function whether this is a user call
or not. I believe this to be an improper solution.
IDEA 2: have a second function - for example _create, which creates
silently. The user centric create will use _create internally and then
- do all the other stuff, so that code will be reused. There will also
be a few new functions - like _load, which will silently fetch the
content of a branch (if using async). open_branch will then internally
use _load, and so on ...

Well - those are the ideas for now. How do you feel about them?
I am very eager to implement those and plan them for the 0.9.9b
release which I can rush out anytime - at latest - this weekend.

Looking forward to hearing from everyone!
Ivan

[Kristian]

I vote "thumbs up" for 1) and 2) !

I also like the 3) IDEA 2. I think the API should reflect if a
function is specifically user centric or not, fx using some kind of
naming convention or similar?

I hope to finish my m3gen sunday! I wonder if your rework for 1.0alpha
will affect the data store API?
Any suggestions/documentation for implementing a datastore?

Kristian

[Roland B]

1) and 2) would be nice!

I am not sure about 3). It seems I am not a developer, because as of
now, I feel no need to create nodes silently :-)
That being said, I tend towards the second idea...

Regards,

Roland

[bernardthetui]

Re 1)
For callbacks that pass the node as argument, please let us pass real
objects with the node not only string name-value pairs.

In JSON, data for a node is passed in attributes as String name-value
pairs.
We could try to pass an object not a string as follows (does not
work):

var myDataObject = {keyValue:3, name:"Peter", phoneNumber:"1234567"};

data : {
title : "Long format demo",
attributes : { "href" : "http://jstree.com", "myDataObject",
myDataObject}
}

A callback could get the data for a node as follows:

callback : {
onselect : function (NODE, TREE_OBJ) {
// We are accessing a DOM methods - not any jsTree node object
method
var atts = NODE.attributes;
alert("NODE.attributes = " + atts);
var attribute = atts.getNamedItem("myDataObject");
alert("attribute = " + attribute);
alert("attribute.name = " + attribute.name);
var myObject = attribute.value
// We cannot get a non-string data object from a DOM
attribute. This is HTML, not data
// THIS IS THE DEAD END - NO OBJECTS ARE SUPPORTED HERE
alert("myObject.phoneNumber = " + myObject.phoneNumber);
}
}

Normally with GUIs, there is a model and a view.

With jsTree, the view is HTML.
When using JavaScript/JSON, the model would typically be in
JavaScript.
I guess, that with jsTree, the model is in JavaScript, too.

Applications of jsTree using JSON, implicitely have their tree object
model in JSON already, whether that is part of application design or
not.

We are now counting THREE more or less complete copies of the model:
JSON, jsTree, and HTML.

The model IS also in HTML as documented in jsTree documentation:
"As you can see you can pass any attributes you like in the attributes
object - in the resulting HTML output those attributes are bound to
the <li> element."

It would be so much easier to use JavaScript with jsTree if the bound
objects of a user model could be passed back with all callbacks.