I think making Tags a plugin might be taking it to an extreme (we would not only not have tags on the default post created on install, but it would eliminate the Tags admin page), but the thought is basically the same: make it easily pluggable.
If we're supposedly setting the example on the 'best' way to implement a vocabulary and its terms with the Tags setup, we're doing a very bad job of it. On Oct 7, 2010, at 10:16 AM, Matt Read wrote: > 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
smime.p7s
Description: S/MIME cryptographic signature
