The method dijit._TreeBase.setChildren sets the isFolder property depending on the length of the childrenArray parameter. It seems that typical meaning of the property isFolder is broken. For example, the Dojo 0.4.x toolkit allows setting this property in an arbitrary way...
bug
You can file a bug. A node should be marked as a folder if the dojo.data item has a children (array) attribute, regardless of the length of that array. And that should happen when the node is created. Looking at the code now it seems like we are querying the children too early, or setting isFolder too late. (isFolder should be set when the node is created, but the children shouldn't be populated until you try to open it.)
is an empty folder possible?
Before a node is created by the dijit._TreeBase.setChildren() method,
the dijit._tree.DataController.onAfterTreeCreate()
and dijit._tree.DataController._onLoadAllItems() methods
set an isFolder flag based on presence of a children attribute.
However, when the node is expanded a new value is set by
dijit._TreeBase.setChildren method based on the actual length of a children attribute.
It seems a node is or is not a folder depending on presence or absence of its children.
Usually the repositories using the folder concept provide a little different meaning.
They allow an empty folder still being a folder, and still rendered as a folder.
That seems to be related to the dijit._TreeBase.makeFolder() method
called by dijit._tree.Controller.onNew().
In my opinion, instead of overiding an isFolder value "on demand" an exception should be thrown when someone attempts to add a child to a node having isFolder=false.
different name?
The isFolder flag is really just meant to control whether there's a +/- expando icon next to the node in the tree. If there are no children then we don't want to display the +/- icon.
So, it seems you are just unhappy with the name "isFolder"... if we changed the name to "hasChildren" or "displayExpando", do you think there's still an issue?
Thanks for the explanation.
Thanks for your explanation. Personally I would prefer the different name because
I am familiar with a term "folder" meaning a container being able to contain children,
and that feature is objective and does not depend on presence or absence of the children.
According to the meaning described above this is not a case.
But that thing cannot make me unhappy because I have just noticed
many interesting changes in the tree implementation (rev. 10386).
The most exciting change seems to me the dijit.Tree.getItemChildren method
and a posibility to override it.
At the end I would like to report a little strange behavior of the tree
when a node's item has a children attribute set to an empty array.
In such a case the tree is renderend perfectly but if I try to expand the node an exception is thrown by the dijit._TreeNode._setChildren.
fixed
Yup, so I fixed the names in [10380] (isFolder → isExpandable, etc.) and I fixed the empty children children attribute problem in [10398]
Yet another empty folder within Trees :-)
I am looking for an elegant solution to declare some node as empty Folder in a Tree.
I use the "dijit.tree.ForestStoreModel" as store model, which by default says that all items without children are leaves.
If I try to set "children:[]",
... items: [ { name:'History', level: 'root', type:'directory', children:[]}, ...I get the following error :
There is the solution to declare a specific "< empty >" child, and deal with when a user try to do something with it, but it is not really nice.
I would expect something like a tag (type: folder)? that may be used to create one non Expandable node until something is appended inside it.
Is it easily realisable?
Tanks in advance for your help and suggestions.
bug
Just sounds like a bug, it should work w/any number of children, even 0. Please file at trac.
=========
Bill Keese
Project Lead (aka BDFL) of Dijit