I've never gone over it fully, but I don't understand the point of having that much custom code in tag/tags when it is just a term/vocab. I think the goal should be to have enough code in terms and vocab. classes so as to reduce in code duplication. It just seems to me that tags classes have become the way to interface with vocab instead of vocab providing a full api for tag classes (or any other) to use (if that makes sense). Last I looked the stuff in tags classes should be in the term or vocab classes.
Also, why isn't tags a plugin. The goal should be to make terms and vocab. as core, and implement different vocabs through (plugin) api. Such as tags and then eventually categories, and anything else people can dream up. On Thu, Oct 7, 2010 at 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. -- Matt Read http://mattread.info http://mattread.com -- 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
