Hello,
On 1/3/07, AD7six <[EMAIL PROTECTED]> wrote:
I heard on the grapevine that the acl code is currently being refactored, so some of what I write below may be obsolete before too long.
Will this be available on the 1.2 or 1.1 branch or both?
On Jan 3, 4:09 am, "Nimrod A. Abing" <[EMAIL PROTECTED]> wrote: <snip> > > I have tried using a stack-based algorithm instead of recursion, but > surprisingly(?!?) it eats up more memory than the recursive version. > Probably because I'm storing objects (which is needed) into the stack. > I'm interested in hearing about others' experience with MPTT > implementations using both the stack-based and recursive approach. Unless I misunderstand and you are not talking about deleting a single (group of) nodes, moving a single (group of) nodes or creating a single (1) node; updating MPTT tables recursively is unnecessary.
I used the following as the basis for my implementation: http://www.sitepoint.com/print/hierarchical-data-database Please see the example tree there to see what I'm talking about. For inserts, I am talking about inserting a single new node in an arbitrary parent. For example, inserting a new node under Meat, say Chicken. I want to insert it so that it goes in between Beef and Pork. i.e., We end up with Beef, Chicken, Pork under Meat. For moves, I am talking about moving a node, and its subtree if present to a new parent. For reordering, I am talking about moving a node within its subtree changing its left to right order. In the example above, say I change my mind and switch Beef and Pork so that we end up with Pork, Chicken, Beef. For deletes, when I delete a non-leaf node, all of its children will be reparented to the immediate parent of their parent.
For deleting a node or group of nodes, the acl_node class already takes care of this with a minimum of sql and affected rows.
Deletes are actually the easiest case to handle. ...
The online acl admin demo allows you to move things around to test this change if you are curious. See http://www.noswad.me.uk/AclAdminDemo/aros (use the Load from user table link if no aros present) or http://www.noswad.me.uk/AclAdminDemo/acos (create something if no acos present and go to the data view) and use the Move this -> form to reparent something(s).
Your example handles only the case for moves as I described above. Delete does not seem to work as I expected in the aros example. I get the message "aro Daniele (and any child aros) deleted." This does not conform to my requirement that its child nodes be reparented to their grandparent. What I need is akin to a child being orphaned and sent to their grandparents when their parents die. Though deleting the children of a node makes much more sense when we are talking about filesystems.
The exact code in use for the demo, incase there are any differences with the ticket code can be seen here: http://www.noswad.me.uk/AclAdminDemo/acl_node (set parent method) I have a partially finished MPTT behaviour, which was based upon the acl_node class and has some additional functionality namely reordering without reparenting using the above logic (so for example, you could if you really wanted use it to design your multi-level menu. and move option 1.1.1.15 to position 1.1.1.7 by reordering up 8 steps). If there are any other MPTT functions that are of interest (I can't think of any) I'd be glad to hear of them.
I'll look into your code as soon as I found the time. I haven't touched my implementation for about three months now after I got sidetracked to work on another project. I've put up the relevant class file here: http://abing.gotdns.com/wobject.php.html in case anyone is interested. The implementation is based mostly on the algorithm described in the sitepoint article above (and from Wikipedia I think). As for using recursion in _rebuildTreeTraversalData() IIRC the reason I did it was because I wanted it to be able to handle the link_order field reordering. Also, I wanted to avoid writing separate SQL statements to handle tree traversal data updates for delete, reparent, and reorder cases. Though I must admit that the link_order field is a bit redundant unnecessary now that I look back at it. I made some optimizations that make sure _rebuildTreeTraversalData() is run only when it is needed. Also, _rebuildTreeTraversalData() avoids recursion if it can (when lft and rgt are unchanged for a node). Comments are very much welcome. Though at this stage, I am thinking of rewriting the whole thing to use the implementation described here: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/461776 But the more I look at that implementation, the more it seems to be suboptimal when it is time to handle very large trees. -- _nimrod_a_abing_ [?] http://abing.gotdns.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Cake PHP" group. To post to this group, send email to cake-php@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cake-php?hl=en -~----------~----~----~----~------~----~------~--~---
