Implementing Tags as Terms

[rick c]

One of the goals for Habari 0.7 is to change tags over to use the
vocabulary and term classes. Over the weekend I created a branch to
work on this. It's located at

http://svn.habariproject.org/habari/branches/tags_as_terms.

At the moment tags functionality appears to be working. The interface
is basically the same as what we are used to with the current tag/tags
interface, with one exception. Since the Term class implements a get()
method, Tag::get() has to have the same interface, so it is now
Tag::get($vocab_id, $term_id) rather than Tag::get($tag). $vocab_id is
the id of the Vocabulary from which you are getting the tag. 'tags' is
the name of the vocabulary in the current code. $term_id is the id of
the tag you are trying to get.

The Tag class is implemented by extending the Term class. Term::objects
() and Term::associate() were fleshed out to be able to add tags to
the object_terms table. A Term::remove_association() method was
created to facilitate remove associations from the object_terms table,
and Utils::object_type_id() was added to the Utils class to facilitate
getting the id of an object type.

Tags are working on site, including being able to use 'tag' and
'tag_text' and 'slug' and 'tag_slug' as we currently do. The tagtray
plugin still works. The Post class has been updated to use the new tag
class, and the install handler has code to transfer one's tags to the
terms table, add the 'tags' vocabulary to the vocabulary table, and
move the contents of tag2post to the object_terms table.

Current issues include:
1. Tags::get() will be very slow when the site has hundreds of tags.
Is there a better way to cast the member of an array from one class to
another than one-by-one in a loop?

2. The string literal 'post' (the object type with which tags are
associated) is scattered through the code.

3. The tags and tag2post tables aren't dropped when upgrading the
database, and the two tables continue to be known to Habari.

This may not be the code we end up with, but it's a start. The code
needs used, in order to spot any bugs, cleaned up, updated to fix the
issues noted above, or thrown away to start over if it's a bad design.

Rick

[Michael C. Harris]

2009/10/13 rick c <rickc...@gmail.com>:

>
> One of the goals for Habari 0.7 is to change tags over to use the
> vocabulary and term classes. Over the weekend I created a branch to
> work on this. It's located at
>
> http://svn.habariproject.org/habari/branches/tags_as_terms.

Great start! We've talked about this on IRC already, but I'm replying here for
official record. Sorry it's a bit late.

> At the moment tags functionality appears to be working. The interface
> is basically the same as what we are used to with the current tag/tags
> interface, with one exception. Since the Term class implements a get()
> method, Tag::get() has to have the same interface, so it is now
> Tag::get($vocab_id, $term_id) rather than Tag::get($tag). $vocab_id is
> the id of the Vocabulary from which you are getting the tag. 'tags' is
> the name of the vocabulary in the current code. $term_id is the id of
> the tag you are trying to get.
>
> The Tag class is implemented by extending the Term class. Term::objects
> () and Term::associate() were fleshed out to be able to add tags to
> the object_terms table.

If Tag doesn't extend Term, but uses it internally, then there is no need to
change the current API. Of course, if the Tag API needs improving, we should
change it, but I think this would be a case of leaking abstraction

> A Term::remove_association() method was created to facilitate remove
> associations from the object_terms table, and Utils::object_type_id() was
> added to the Utils class to facilitate getting the id of an object type.

Minor, but I'd prefer that a method to remove an association was symmetrical
with the method to add an association, so either associate() and dessociate()
or add_association() and remove_association().

> Current issues include:
> 1. Tags::get() will be very slow when the site has hundreds of tags.
> Is there a better way to cast the member of an array from one class to
> another than one-by-one in a loop?

Not off the top of my head. Hopefully someone else can chip in.

> 2. The string literal 'post' (the object type with which tags are
> associated) is scattered through the code.

Is that a problem? Do we want this to enable generic tagging of objects?

--
Michael C. Harris, School of CS&IT, RMIT University
http://twofishcreative.com/michael/blog
IRC: michaeltwofish #habari

[rick c]

On Oct 19, 7:15 am, "Michael C. Harris" <michael.twof...@gmail.com>
wrote:
> 2009/10/13 rick c <rickcock...@gmail.com>:

>
>
>
> > One of the goals for Habari 0.7 is to change tags over to use the
> > vocabulary and term classes. Over the weekend I created a branch to
> > work on this. It's located at
>
> >http://svn.habariproject.org/habari/branches/tags_as_terms.
>
> Great start! We've talked about this on IRC already, but I'm replying here for
> official record. Sorry it's a bit late.
>
> > At the moment tags functionality appears to be working. The interface
> > is basically the same as what we are used to with the current tag/tags
> > interface, with one exception. Since the Term class implements a get()
> > method, Tag::get() has to have the same interface, so it is now
> > Tag::get($vocab_id, $term_id) rather than Tag::get($tag). $vocab_id is
> > the id of the Vocabulary from which you are getting the tag. 'tags' is
> > the name of the vocabulary in the current code. $term_id is the id of
> > the tag you are trying to get.
>
> > The Tag class is implemented by extending the Term class. Term::objects
> > () and Term::associate() were fleshed out to be able to add tags to
> > the object_terms table.
>
> If Tag doesn't extend Term, but uses it internally, then there is no need to
> change the current API. Of course, if the Tag API needs improving, we should
> change it, but I think this would be a case of leaking abstraction
>

I've committed a second pass at the implementation. I took your
advice. The Tag class now extends the QueryObject class directly.

> > A Term::remove_association() method was created to facilitate remove
> > associations from the object_terms table, and Utils::object_type_id() was
> > added to the Utils class to facilitate getting the id of an object type.
>
> Minor, but I'd prefer that a method to remove an association was symmetrical
> with the method to add an association, so either associate() and dessociate()
> or add_association() and remove_association().
>

Good point. I renamed the method dissociate().

> > Current issues include:
> > 1. Tags::get() will be very slow when the site has hundreds of tags.
> > Is there a better way to cast the member of an array from one class to
> > another than one-by-one in a loop?
>
> Not off the top of my head. Hopefully someone else can chip in.
>

The re-implementation of Tags made this a lot easier. The rows are now
returned directly as Tag objects, removing the need to loop through
them to turn them into tags.

> > 2. The string literal 'post' (the object type with which tags are
> > associated) is scattered through the code.
>
> Is that a problem? Do we want this to enable generic tagging of objects?
>

I didn't think about enabling generic tagging of objects. I just don't
like magic numbers or strings all through the code. For now, I've just
placed the string as a static member of the Tags class, and added a
method to tags to get it.

Rick

[David Latapie]

Hi,

On 13 oct, 02:45, rick c <rickcock...@gmail.com> wrote:
> One of the goals for Habari 0.7 is to change tags over to use the
> vocabulary and term classes. Over the weekend I created a branch to
> work on this. It's located at
>
> http://svn.habariproject.org/habari/branches/tags_as_terms.

Please explain the sdvantages. I know a bit of Drupal's taxonomies, if
that may help explaining.

[David Latapie]

Also : since I do not see any cantegory entry, shall I assume tag will
serve the purpose of categories? I think there is too much redundancy
between tags and categories so I'm OK with it, but there is one thing
tags do not support (well, at least WordPress tags): hierarchy. I
personally used hierarchical tags on my Drupal install. That was not
perfect because I could not decide to see content + subcontent (it was
content XOR subcontent, and I wanted content AND subcontent)

[Michael C. Harris]

2009/11/14 David Latapie <david....@gmail.com>:

> On 12 nov, 14:39, David Latapie <david.lata...@gmail.com> wrote:
>> On 13 oct, 02:45, rick c <rickcock...@gmail.com> wrote:
>>
>> > One of the goals for Habari 0.7 is to change tags over to use the

>> > vocabulary and term classes...

>>
>> Please explain the sdvantages. I know a bit of Drupal's taxonomies, if
>> that may help explaining.

The ability to relate objects to one another can be used in all sorts of ways.
For example, menus, page hierarchies, threaded comments, categories are just a
few I can think of off the top of my head. Tags is another obvious one, so
we're now using a tags vocabulary, and that's been merged to trunk. One of the
advantages of this is that, at least in theory, now any object can be tagged,
not just posts.

> Also : since I do not see any cantegory entry, shall I assume tag will
> serve the purpose of categories?

Categories will be implemented in a plugin. It's also possible that tags might
be taken out of core and made into a plugin sometime in the future, we'll see.

[David Latapie]

2009/12/4 Michael C. Harris <michael...@gmail.com>:

> The ability to relate objects to one another can be used in all sorts of ways.
> For example, menus, page hierarchies, threaded comments, categories are just a
> few I can think of off the top of my head. Tags is another obvious one, so
> we're now using a tags vocabulary, and that's been merged to trunk. One of the
> advantages of this is that, at least in theory, now any object can be tagged,
> not just posts.

Looks very promising!

> Categories will be implemented in a plugin. It's also possible that tags might
> be taken out of core and made into a plugin sometime in the future, we'll see.

Yes, this sounds logical to me to remove tags from core (most blogs do
not use tags or categories, even though I am an ardent partisan of
adding metadata and structure).

--
</david_latapie>
http://david.latapie.name/ U+0F00
Proper Preparation Prevents Poor Performance
On ne fait qu’une seule première impression