You are correct, I do rely on a root node, but I think I've already
got this one figured out. Even if there isn't a real root node, there
is an implicit root node. All eight records in the table may be on the
same level, but they share the same parent: null. I'll fix it if I run
into problems, but I don't think it will.
Yeah, it is a bit like cheating, but the idea of non-existent root
sure has made edge-case handling a lot easier.
Nathan
On Nov 3, 10:21 am, drzax <[EMAIL PROTECTED]> wrote:
> Another thing that's been bugging me is that this whole structure
> depends on there being a single root node in the MPTT. That's not
> necessarily the case (in fact, it's probably unlikely to be the case).
> Some of the manipulation functions of MPTTNode will need to be
> replicated in MPTT (specifically, append() and prepend()) in order to
> manipulate nodes that aren't child nodes.
>
> On Nov 3, 9:48 am, drzax <[EMAIL PROTECTED]> wrote:
>
> > Damn...thought I sent this on Friday. Oh well...
>
> > That's starting to look really good, and well fleshed out. Thanks for
> > sharing. I'm still not sure I've quite understood the MPTT
> > constructor. What are the $table and $fields parameters for?
>
> > This is looking excellent for working with things like nested
> > categories (with each category containing a bunch of posts or pages),
> > but I'm wondering if you've considered how it might be used to create
> > a nested menu of pages (for example). That is, where the MPTTNodes
> > aren't just a categorisation of another object, but represent a single
> > other object in a 1-1 relationship. Also worth thinking about is the
> > possibility that those other objects in the 1-1 relationship with
> > records in the 'terms' table might be different types of object, all
> > within one MPTT hierarchy.
>
> > This kind of thing will obviously be possible (the DB structure
> > already supports it) but I think it's definitely worth thinking about
> > at this early stage and making sure the classes are easy to use in
> > this manner, otherwise there will be teAmptation to go around the MPTT
> > classes for specific purposes like (like building menus that contain a
> > mix of content types, for example).
>
> > I'm not sure I've explained what I mean there, particularly well, so
> > if it unclear, let me know and I'll try harder. Looking forward to
> > seeing the first commit and playing with the code.
>
> > Cheers,
> > Simon
>
> > On Oct 30, 6:08 pm, Nathan Hammond <[EMAIL PROTECTED]> wrote:
>
> > > In my work so far I've got it using a parent field. It just made more
> > > sense to me from a speed perspective. Fortunately, the decision about
> > > the final approach can be resolved later since that won't change the
> > > interface, just the underlying code. I'll commit it as a branch, let
> > > people test it, and see what they think.
>
> > > Since I'm basing my approach off of JavaScript's DOM traversal methods
> > > I've got three basic objects, described in detail below. In short, the
> > > only concern of yours that I've not addressed, the appending being a
> > > method of the node, is JavaScript's approach. You'll see below that
> > > I'm trying very hard to craft something both intuitive and familiar. I
> > > agree with you that since it is a bigger change in this model than in
> > > the DOM approach (affecting all subsequent nodes) that it might
> > > possibly be best to implement this as an invocation of an MPTT method,
> > > but for now I'm sticking with JavaScript's approach as it is easier.
>
> > > *ponder*
>
> > > I do however retain a reference to the MPTT object on the node and I
> > > guess it would be relatively trivial to alias the modification
> > > functions back upstream to that object... (using a mixed JS and PHP
> > > notation)
> > > $node->remove() = function () { $this->mptt->remove($this); }
>
> > > Bah, you're right, and I'll do it later. I only have to figure out how
> > > I want to handle the MPTTSet stuff and then I'm done with r1. Which
> > > means I can put it up so others can contribute and I won't hold things
> > > up when I get distracted by the other project I'm working on (a
> > > Dashboard widget to enable/disable a local caching DNS server in OS
> > > X).
>
> > > Thanks Simon! I really appreciate your input, I've made a number of
> > > changes for the better because of it.
> > > Nathan
>
> > > ***
>
> > > 1. MPTT. This stores the definition of the table and provides some
> > > basic global methods. You can think of this like the document object
> > > in JavaScript.
> > > __constructor($table, $fields) - Takes $table and optionally $fields
> > > to define the rules it is working under.
> > > get_node($id) - (document.getElementById) - Takes a node ID.
> > > create_node($paramarray) - (document.createElement) - Takes an
> > > associative array to define necessary fields.
> > > get_leaf_nodes() - (document.querySelectorAll) - Returns leaf nodes.
> > > sort_level($related, $sortBy) - Passed either a MPTTNode or a node ID
> > > and a sort clause.
> > > replace_node($related, $new) - Passed either a MPTTNode or a node ID
> > > and the new node.
> > > move_node ($method, $related, $new) - Used to avoid traversal if you
> > > already know everything you need.
>
> > > 2. MPTTNode. This represents a specific node. It presently does not
> > > extend QueryRecord, but now that you mention it, it will.
> > > __constructor($mptt, $nodeInfo, $last) - (jQuery) - Takes a reference
> > > to the defining MPTT object, this node's info, and the $last most
> > > recent selection (for chaining).
>
> > > /* Attributes */
> > > depth() - Returns the depth of the current node.
>
> > > /* Traversal, Chaining*/
> > > end() - (jQuery().end()) - Returns the previous selection.
> > > parent() - (jQuery.parent()) - Returns the parent of the current node.
> > > child($n) - (jQuery.find(> :n)) - Returns the Nth child of the current
> > > node.
> > > prev() - (jQuery.prev()) - Returns the previous sibling of the current
> > > node.
> > > next() - (jQuery.next()) - Returns the next sibling of the current
> > > node.
> > > prevAll() - (jQuery.prevAll()) - Returns all previous siblings.
> > > nextAll() - (jQuery.nextAll()) - Returns all following siblings.
> > > siblings() - (jQuery.siblings()) - Returns all siblings.
> > > children() - (jQuery.children()) - Returns all children.
> > > ancestors() - (jQuery.ancestors() - with a plugin I wrote for jQuery)
> > > - Returns all ancestors.
> > > descendants() - (jQuery.descendants() - with a plugin I wrote for
> > > jQuery) - Returns all descendants.
> > > andSelf() - (jQuery.andSelf()) - Returns $last merged with current.
>
> > > /*Modification*/
> > > append($node, $sort = false) - (document.element.appendChild())
> > > append_to($node, $sort = false) - (document.element.appendChild())
> > > insert_before - (document.element.insertBefore())
> > > insert_after - (document.element.insertAfter()) (often prototyped in)
> > > remove - (document.element.removeChild())
>
> > > 3. MPTTSet. This extends ArrayObject right now and I've not fully
> > > fleshed it out (which is why I've not asked for a branch yet). The
> > > basic idea is that it will provide some of the base level
> > > functionality that MPTTNode does (end(), in particular) and then
> > > determine how to handle other functions accordingly.
>
> > > On Oct 29, 7:15 am, drzax <[EMAIL PROTECTED]> wrote:
>
> > > > Hi Nathan,
>
> > > > I've been thinking about this sporadically over the past couple of
> > > > weeks and I'm keen to see if you've made any progress. I have a couple
> > > > of questions about your proposed solution, which (aside from my
> > > > previous points) I quite like the look of.
>
> > > > First of all this line:
>
> > > > $mptt = new MPTT( array( 'table' => 'mytree' ) );
>
> > > > I've assumed (maybe incorrectly) that an instance of the MPTT class
> > > > basically represents a record in the vocabularies table. If I'm right
> > > > with that assumption:
> > > > - will it extend QueryRecord?
> > > > - what is the data being passed to the constructor?
>
> > > > Also, I've assumed that MPTTNode essentially represents a record in
> > > > the terms table.
>
> > > > In relation to this line:
> > > > $return = $mptt->get_node(27)->parent()->child(0)->append($mptt-
>
> > > > >create_node( array( 'slug' => 'javascript' ) ));
>
> > > > This seems to indicate that append(MPTTNode) is a method of the
> > > > MPTTNode class, which doesn't quite add up. Given that (almost) every
> > > > append action will necessarily involve manipulation of more than one
> > > > node in the tree, shouldn't the append method be part of the MPTT
> > > > class?
>
> > > > None of this is by way of criticism, just looking to clarify your
> > > > thoughts. I'm looking forward to seeing your implementation of this.
> > > > BTW, did anyone make a decision re: the parent field?
>
> > > > Cheers,
> > > > Simon
>
> > > > On Oct 17, 6:06 am, Nathan Hammond <[EMAIL PROTECTED]> wrote:
>
> > > > > Regardless of the eventual underlying implementation in terms of
> > > > > adjacency or MPTT, here is the syntax I'm coming up with:
>
> > > > > $mptt = new MPTT( array( 'table' => 'mytree' ) );
> > > > > $return = $mptt->get_node(27)->parent()->child(0)->append($mptt-
>
> > > > > >create_node( array( 'slug' => 'javascript' ) ));
>
> > > > > The way to describe that:
> > > > > 1. From the MPTT object defined by the table mytree;
> > > > > 2. Get node id 27;
> > > > > 3. Get node 27's parent;
> > > > > 4. Get the first child of node 27's parent;
> > > > > 5. Append the node that is created by the same MPTT object to the
> > > > > first child of node 27's parent.
> > > > > 6. Assign the return value of the last operation (the most recently
> > > > > touched node, in this case the new one) to $return.
>
> > > > > Of course, that is *way* overkill and anybody who is fiddling with
> > > > > their MPTT tree in that manner might need to get their head looked at.
> > > > > However, I'd rather enable that degree of complexity to be easily
> > > > > accomplished so that nobody has any need to modify this base class. By
> > > > > creating such an easy to use API I think we'd manage to avoid the
> > > > > problem of somebody wanting to directly fiddle with the tables.
> > > > > Hopefully.
>
> > > > > In any case, I'm basing this syntactical design off of JavaScript, and
> > > > > jQuery in particular, as that is my primary expertise. To accomplish
> > > > > this I am writing two classes: MPTT, representing the entire tree; and
> > > > > MPTTNode, representing just a
>
> ...
>
> read more »
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/habari-dev
-~----------~----~----~----~------~----~------~--~---
