That loud explosion y'all just heard coming from the northern Midwest was the sound of my head exploding after reading this thread.
-- Randy Walker On Oct 16, 2010, at 7:01 PM, Owen Winkler <[email protected]> wrote: > 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 -- 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
