Some initial comments:
I don't see any harm in having a Terms class that is an ArrayObject
allowing you to act on multiple tags at once. I'm sure there would need
to be a reason to, internally if not externally. It's not strictly for
mass delete, but re-parenting Term objects all at once could be useful
especially during move operations. The Vocabulary class would simply
return the array via the Terms class and nothing else would need to change.
I think that Vocabulary::get_terms() should return a consistent data
type. Whether there is a Terms or just an array of Term, I do think it
should always return an array, even if there is one. As a recipient of
the result, you shouldn't need to test for the type of value returned,
simply assume that it's an array of some kind.
Incidentally, I believe that Posts::get() always returns an array unless
you specifically request only one. I think if we persisted this
behavior to Vocabulary::get_terms() that would also be fine. Also note
that Posts::get() returns a Posts ArrayObject, not just a plain array.
There are a handful of places in the pcode where naming can go wrong.
If a vocabulary name has a character in it that is not legal for
variable use, for example, then $post->vocabulary->{name here} would be
a problem. Likewise, there is no mention of tag slugs in the pcode,
which are a requirement for URL creation based on tags/terms. This
isn't to say there is no solution for it, just that it's not present in
this solution.
If terms are returned with a post, I think we could do well to use a
syntax like that used for comments. For example, $post->terms alone
would return all Term objects associated to the post.
$post->terms->vocabname or $post->terms['vocabname'] would filter the
list to only those qualifying Terms. This would be done via the Terms
class I mentioned earlier.
The location of the functionality of adding and removing terms has
always kind of bothered me, but thinking about it some more, the
behavior of adding a term is closely tied to the settings of a
vocabulary. When you add a new term, you may have a choice between
adding it as a free tag or hierarchical category. Where does the
enforcement of that take place?
Is the suggestion that hierarchical vocabularies necessarily extend the
Vocabulary class to HierarchicalVocabulary so that they can incorporate
those features? Does the Term class then also need to be extended to
HierarchicalTerm so that it has the methods required to allow it to be
re-parented?
When we want to replicate the behavior, would it always be necessary to
create a subclass, or is it possible to assign behavior properties to
the base vocabulary class that allow it to change the way it operates
within different instances?
One place I can imagine that this might be a problem is with unique
hierarchical categories versus a vocabulary-driven menu system. In the
former, a term may be associated to multiple posts. In the latter, each
term must be associated to exactly one post. The exclusivity of a term
such as this is an additional behavior that would be useful to define
for both hierarchical vocabularies as well as flat tagging vocabularies.
Using a system that exclusively uses class descendants to add this
functionality could result in something not so great.
I'm curious to hear the solutions that this idea could present to solve
these issues.
Owen
--
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
