Love Fuel?    Donate

FuelPHP Forums

Ask your question about FuelPHP in the appropriate forum, or help others by answering their questions.
Fuel Nested Sets
  • I created an extension of the ORM-package to handle nested sets. This package is influenced (and in parts copied) from @Harro Verton but since his fuel-nestedsets package was not perfectly what I was looking for, I quickly wrote my own package.
    It even fits in nicely with the ORM-syntax as you can e.g., use $object->save() to save the node-object.

    If you're interested in checking out my package, head over to
    and also check out the

    Right now the package only supports single-root nodes i.e., you can only store one tree within one database-table. Multi-tree support is kinda implemented so far, however it is not yet tested nor working properly. So, please don't rely on this feature unless you love debugging ;)

    If you have any questions, ask them here. Issues and pull-requests can be made on github. However, in case you don't have an account at GitHub, feel free to issue and code-improve here ;)
  • To bad you've put this effort in, as nested sets will be part of the ORM package in 1.7, it's currently being finalized and tested.

    I will definately have a look at your changes, and if you don't mind cherry-pick improvements that we haven't thought of yet. Especially at what you have done with save(), since the issue with that is that you need to know where to insert it in the tree (which you can't do with just calling save).
  • Too bad, should have had a look at 1.7/develop. But anyway, it was a good practice for me to get going with FuelPHP.

    Sure, you can cherry-pick methods of my model. I'd feel honored if some of my code made it into fuel's core :)
    Regarding the save()-thingy: I ran across the same problem which is why I ended up doing some preliminary checks on the object (like determining if a parent node was set) before actually calling parent::save(). But yeah, you've probably seen it while digging through my code ;)
  • I've looked at your code, and really like the way the chaining way of defining move operations.

    One thing I wonder though: what is the use-case for shifting the tree up when deleting a node? It would destroy the entire structure of the tree, so I'm trying to understand why you would need this.

    Same for the level column, want is the use case? And if you need it, do you need it that often that it warrants processing on every change of the tree, compared to calculating the level when you need it?
  • When deleting a tree I'm only shifting up the child-nodes of the tree. This behavior is copied from other implementations of Nested-Sets behavior e.g., Joomla. This should also not destroy the tree-structure - well, okay, depends on what you consider "destroy". But I'd say, it doesn't destroy the structure. It just changes it.

    I implemented the level-column because the level can come in handy when getting a tree and exporting it in e.g., a form-dropdown with an indentation proportional to the level. Actually, the level can be grabbed with the MySQL-Query, however, since rows from the table are mapped to ORM-Models (which usually don't have the level-property since it's dynamically generated by the query) you don't have the level-property available. Therefore, I added it to the table and model and made it available as a model property.
    I actually was thinking of creating a "blank" node which would be passed to \Orm\Model::query()->as_object() but that was beyond my skills and time available. Yet I guess, this is the way to go as I've seen this kind of implementation in a Model for the Zend Framework, and one for Doctrine 2. That's all due to PDO::fetchObject as this does early-binding which means, the class properties are set before __construct() is called. This can be avoided by using something along the lines of $stmt->setFetchMode(PDO::FETCH_CLASS|PDO::FETCH_PROPS_LATE, "className", $constructorArguments);

    How is your code handling a node's level? By the way, the implementation you mentioned, can it be found on github at fuel/orm? I was curious about your code but couldn't find anything that says "nested set" or alike.
  • I've committed our version a few days ago:

    I've implemented your delete() behaviour too, a standard delete only deletes the node (and shifts the rest up), a delete_tree() deletes the entire (sub)tree.

    Currently there is no level implemented, since I haven't found a use-case for it, that's why I asked why you have implemented it that way. There is a depth() method available that would calculate the level of a node to accomodate people needing that though.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

In this Discussion