On Oct 7, 1:00 am, Chris Meller <[email protected]> wrote: > So I've finally gotten around to checking out how we've migrated Tags into > the new Vocabulary / Terms structure and I've got to say... I'm confused. > Every vocabulary and term is going to function exactly the same way, why do > we have these massive wrapper classes for them? Tags is 240 lines of code and > Tag clocks in at 280. They're seriously not doing anything special, why is > there so much code? > > The way I envisioned these classes to work, all the logic would be in the > Vocabulary and Term classes. You're getting all / some / one of the Terms in > a Vocabulary, you're getting all / some / one of the objects a Term is > associated with... None of this is any different for any Term. If a plugin is > trying to create a new vocabulary and new terms, they should be able to throw > together a couple of lines for a class for each and be done with it. > > When you're defining, say, Tags as the Vocabulary and Tag as the Term, you > should have something like: > > class Tags extends Vocabulary { > > // this is the information that you'd have passed manually to > Vocabulary::create() before > public $name = 'tags'; > public $description = 'Tags, yay!'; > > // create and return objects of this type when we get lists > public $term_class = 'Tag'; > > // and what kind of object to terms in this vocabulary get linked to? > we do this as well, although we should improve it - why can't i use a > vocabulary to link against multiple types of objects? > public $object_type = 'post'; > > } > > class Tag extends Term { > > // indicate which vocabulary we belong to - this is the same as it's > currently done, should link up with Vocabulary::$name > public $vocabulary = 'tags'; > > } > > The base Vocabulary and Term classes should contain all the logic for getting > and creating their respected objects, returning a tree of terms, etc. Unless > there is something incredibly specific, there should be no code in any of the > child classes. Think of it like SQLiteConnection, where we only have to alter > things that don't correspond with the "standard", like sql_t(). Right now we > have Term and Vocabulary classes that are manually called for every operation > in Tags and Tag, while they should be extending them instead. > > Rick and Mike were talking about a related topic on IRC, so I brought this up > with them. Rick said this was really the way he'd originally envisioned > things working but had somehow been talked out of it by Owen and the > Aussie... I'm curious as to why, since he didn't remember anything more than > something to do with "inheritance" and QueryRecord. > > The Vocabulary and Term classes could still extend QueryRecord, allowing you > to use ->insert() and ->delete(), just as you normally would, so I'm not sure > what argument there could be there. Perhaps I'm misunderstanding everything > and we just need to do some cleanup on the duplicate code we've got between > our classes and extend them but it seems like we're teetering on the edge of > what I'm looking for yet deliberately staying away for some reason. >
To be clear, I had only considered deriving Tag from Term. not Tags from Vocabulary. While deriving Tags from ArrayObject may be poorly thought out, it acts more as a container for Tag objects than serving the other functions embodied in several of the static methods of Vocabulary. Many of Vocabulary's staic methods, such as - get_all_object_terms(), get_all(), get_all_object_terms(), rename(), names() - make sense for a vocabulary in the abstract, but not for a specific vocabulary. Others, such as - get(), get_by_id(), rename(), while logical identifiers for methods in a specific vocabulary, are used for a different purpose in the Vocabulary class. In PHP, unless I'm mistaken, static members of a base class are not overridden in derived classes, so calling Tags::get_by_id(), for example, would result in Vocabulary::get_by_id() being called and incorrect results. The CRUD methods of the Vocabulary class make no sense at all to me in the context of a specifc vocabulary, unless they are methods used to manipulate terms within that vocabulary. Again, in the case of static methods, this would lead to incorrect results as the corresponding methods in the Vocabulary class would be the actual ones called. These things all seem sufficient reasons not to derive a specific vocabulary class from Vocabulary. Rick -- 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
