Guest User

Untitled

a guest
Jun 18th, 2018
99
0
Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
text 6.49 KB | None | 0 0
  1. <?php
  2.  
  3. class Term extends QueryRecord {
  4.  
  5. protected $vocabulary; // set by child classes to indicate which vocabulary your term relates to
  6.  
  7. // these two would be emulated by __get() and __set() so that they're actually stored in $this->fields
  8. // for QueryRecord to work but this would be the public API
  9. public $term; // the slugified version of the term name
  10. public $display; // the raw term name for display
  11.  
  12. // these wrap around their QueryRecord parents
  13. function insert () {}
  14. function delete () {}
  15. function update () {}
  16.  
  17. function attach_to_object ( $object_id, $object_type ) {
  18.  
  19. // attach $this->id (no need to pass in one) to the object of $object_type with id $object_id
  20.  
  21. // $object_type would default to the type of object a vocabulary is set to link against, if it is limited to a particular type
  22. // otherwise, presumably it would default to 'post' for convenience
  23.  
  24. }
  25.  
  26. function detach_from_object ( $object_id, $object_type ) {}
  27.  
  28. function rename ( $new_name ) {
  29.  
  30. // rename $this->term to $new_name. should handle making sure it's available in the given $vocabulary
  31. // as well as merging it with an existing tag of the same name
  32.  
  33. // just like deleting terms (see note in Vocabulary), you do this on a single term, not on a group of terms
  34. // which means it goes in Term, not Vocabulary
  35.  
  36. }
  37.  
  38. function next () {
  39.  
  40. // get the next Term in the tree, if Vocabulary is heirarchical
  41. // similar methods for working up and down the tree, getting children, etc. would be needed
  42.  
  43. }
  44.  
  45. // note that there is no get() method. you don't directly fetch a term, you fetch terms from a vocabulary
  46.  
  47. }
  48.  
  49. class Vocabulary extends QueryRecord {
  50.  
  51. protected $term = 'Term'; // overridden by child classes to indicate which class we use to represent terms. ie: which class should Vocabulary tell PDO to return results as?
  52. protected $vocabulary; // set by child classes to indicate the name of this vocabulary (matches up with Term::$vocabulary)
  53.  
  54. // these wrap around their QueryRecord parents
  55. function insert () {}
  56. function delete () {}
  57. function update () {}
  58.  
  59. static function create ( $params = array() ) {
  60.  
  61. // a factory method that returns a newly-created Vocabulary object after calling ->insert() on it
  62. // this would really only be useful if you're creating some kind of dynamicly named vocabulary and can't create
  63. // a separate class that extends Vocabulary like you normally would
  64.  
  65. }
  66.  
  67. function get_terms ( $params = array() ) {
  68.  
  69. // works the same as Posts::get(), parsing out the parameters from the array
  70. // and returning all matching terms for vocabulary $this->vocabulary (so you don't have to
  71. // pass in 'vocabulary' => 'tags', like you do 'content_type' => 'entry' for Posts calls)
  72.  
  73. // this would replace get_all(), get_by_id(), get_by_name(), etc.
  74.  
  75. // we would then return a simple array of $term objects - either the generic Term class or any other class specified in self::$term
  76.  
  77. // since we only return an array(), which is really all that the current Tags class is once its methods are moved into
  78. // this generic Vocabulary class, there's no need for a "container" class anymore.
  79. // $post->tags is an array, not a Tags object emulating an array
  80.  
  81. }
  82.  
  83. // note there are no other term-modifying methods (like delete_term()).
  84. // you get terms and perform operations on individual term objects instead, just like we do with posts
  85.  
  86. // we would also add handling for the different vocabulary features (heirarchical, etc.) in here,
  87. // as well as getting and managing the tree of terms, if applicable
  88.  
  89. // also note there is not necessarily an $object_type parameter. a vocabulary could be linked to any type of object
  90. // so limiting it always to a single type is not appropriate. that's why you always pass an $object_type to Term::attach_to_object().
  91. // there should, however, be the option to specifically link a vocabulary to a single type of object
  92.  
  93. }
  94.  
  95.  
  96. // now we set up our default Tags structure!
  97.  
  98. class Tag extends Term {
  99.  
  100. protected $vocabulary = 'tags';
  101.  
  102. // that's it, there is nothing special about a Tag object, it behaves just like any other term,
  103. // so all the methods for dealing with tags are actually in Term
  104.  
  105. }
  106.  
  107. class Tags extends Vocabulary {
  108.  
  109. protected $term = 'Tag'; // our Terms are the Tag class, return that type of object for all terms
  110. protected $vocabulary = 'tags'; // the name of our vocabulary is 'tags' - linked with Tag::$vocabulary
  111.  
  112. // again, there is nothing special about tags, any functions we might need or actions to be performed on them are in
  113. // the base Vocabulary class. getting tags works just like getting any other type of term, no modifications are
  114. // required to Vocabulary::get_terms().
  115.  
  116. }
  117.  
  118.  
  119. // and finally, examples of using the classes
  120.  
  121. // in the Post class, you load tags for the post:
  122. $post->tags = Tags::get_terms( array( 'object_type' => 'post', 'object_id' => $post->id ) );
  123. // $posts->tags would be set to array( $tag1 instanceOf Tag, $tag2 instanceOf Tag, ... )
  124.  
  125. // a better structure, however, would be more generic. every time a post is loaded, we would retrieve all its related
  126. // terms, regardless of vocabulary, and set $post->vocabulary->%vocabulary_name% = array( %vocabulary_terms% )
  127. // so instead of $post->tags we would access them at $post->vocabulary->tags instead.
  128.  
  129. // delete the 'foo' tag entirely, including associations with any objects
  130. $tag = Tags::get_terms( array( 'name' => 'foo' ) );
  131. // similar to Posts::get(), if it's a single tag i would return simply a single tag object, not an array with a single entry
  132. $tag->delete();
  133. // boom, it's gone and works just like deleting a post
  134.  
  135. // say i'm dynamically determining the name of a vocabulary - maybe i let the user create any type of vocabulary they want
  136. // in that case i don't know the name of the vocabulary and can't create a class to extend Vocabulary. no big deal, it's convenient
  137. // but not required:
  138. $tags = Vocabulary::create( array( 'vocabulary' => 'tags' ) );
  139. // the vocabulary is created because create() calls ->insert() before it returns the Vocabulary object
  140.  
  141. // from now on i can get the vocabulary:
  142. $tags = Vocabulary::get( array( 'vocabulary' => 'tags' ) );
  143. // or:
  144. $tags = new Vocabulary( array( 'vocabulary' => 'tags' ) );
  145.  
  146. // and get some terms from it:
  147. $terms = $tags->get_terms( array( 'name' => 'foo' ) );
  148. // or all of them for a given post:
  149. $terms = $tags->get_terms( array( 'object_id' => 123, 'object_type' => 'post' ) );
  150.  
  151. ?>
Add Comment
Please, Sign In to add comment