Blog entry describing some changes here:
http://stannard.net.au/blog/index.cfm/2008/8/25/Nested-Set-Trees-in-ColdFusion-v08

Documentation here:
http://stannard.net.au/blog/page.cfm/nested-set-trees

Download here:
http://nstree.riaforge.org

Please add any comments on this new version against the new blog entry, thanks.

Thanks for the feedback,
Hussein

It should be ready within the next two weeks (all going well it may be ready this coming weekend).

The primary changes include multi-tree support and object nodes (rather than struct nodes) that you can use for some nicer syntax.

Rather than:
nst().newFirstChild(node,5)

you can use:
node.newFirstChild(5)

The previous syntax will continue to be available.

So, should have an update shortly!

Kevan

I hope you are in good shape.

I was wondering when you will be rolling out the next NSTree version with real Multi-Tree support and the likes. I am really excited about this next release as I plan on making it an integral part of most systems I build in the future.

Thanks,
Hussein

I have several enhancements planned but honestly had not considered a roadmap. Even though the overall scope of the project is relatively small, a roadmap may be worthwhile to at least gauge progress to 1.0.

In the meantime, some of the enhancements planned include:
* Multi-tree support
* Move to more OO style API
* General performance enhancements.

Thanks for the suggestion.

(What is the roadmap that you have set the version numbers on? Not getting to 1.0 can hurt a project very deeply.)

Thanks. Since Dan’s comments above I have been considering ways in which to supply default values. I am planning to make a change as follows:

Either

a) Supply all parameters implicitly:
init(dsName,dsUser,dsPass,nstTable,nstId,nstLeft,nstRight), or

b) Supply mandatory parameters explicitly:
init(datasource="dsName",nstTable="nstTable")

The parameters for the library initialisation would then be

datasourceName – required
datasourceUsername – optional, default=""
datasourcePassword – optional, default=""
nstTable – required
nstId – optional, default="id"
nstLeft – optional, default="lft"
nstRight – optional, default="rgt"

By optional values I mean the <cfargument> params. I realize this is a pain if someone has software already built on the platform… but having fixed required arguments for things like dbusername, dbpassword are not compliant with how most people use CF. In fact many developers don’t even have access to that information! There are many shops that have coders and DBAs and hardware guys maintaining the web in three different layers. In those cases your tool is totally without use to the coders. (And occasionally some of those are my clients.)

Yes, node.left etc. is a much nicer syntax. Definitely worth reviewing.

The "move up" and "move down" error should be fixed in the current release.

To identify the first and last children of a node the first thought that comes to mind is:

firstChild.left = parentNode.left + 1
lastChild.right = parentNode.right – 1

I’ll add something to the demo that uses this idea, but it requires some extra subqueries to look up the parent node details.

Re: Optional values

Can you expand on your idea here? Where would the optional values be used?

Re: Forum App

This is a great example of where multiple tree support would be required. I am looking into this as the moment.