On Oct 16, 2010, at 7:01 PM, Owen Winkler 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 don't see any harm in it either, eliminating it was purely for logical
reasons. If we have a Terms class, what do we call the Tags vocabulary
implementation of it? Tag is a Term, Tags is the Vocabulary... TagTerms is the
"collection" class?
The vast majority of operations we perform are on single objects or looping
through a set of objects and performing operations on each one. Providing batch
operations is a purely secondary concern at this point and would likely only
serve to muddy the waters and confuse people even more, that's why I ignored it
entirely.
>
> 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.
Posts::get() can be instructed to return a single object (based on the PDO
function it's instructed to use). Emulate this behavior, whatever it is.
>
> 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.
I am not opposed to this idea, I simply see no instance in which I would want
to get all the terms related to a post regardless of the vocabulary they exist
in. When I'm displaying a post I want to know the terms in the 'tags'
vocabulary and the 'category' vocabulary so I can display these lists... I'm
unable to picture an instance in which I would want both lists combined. When
displaying comments you only want to display the approved comments on the live
page, so this isn't an accurate analogy.
Like I said, not opposed to the idea, I just don't see a use case worth
justifying the added complexity.
>
> 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?
Whether it is a free tag (or should be a member of a restricted set) is
determined by the Vocabulary. Presumably this validation code would go along
with any other "does this term already exist?" type validation logic.
As far as the hierarchical category, I really have no idea how this is expected
to work. There isn't any code presently that deals with hierarchical
vocabularies, so I don't have much to base my revision on.
>
> 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?
The final example illustrates instances in which you can't / don't want to
create a subclass. Subclasses simply encapsulate some of the variables and make
it incredibly easy to reference a specific vocabulary, they don't provide any
additional functionality. You can always call the Vocabulary class directly,
assign its features, etc. I'm not sure why you would want to change the rules
of a vocabulary on the fly, but you could if you wanted to.
>
> 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.
As I said, we have yet to flesh out any of the hierarchical structure issues.
Free tag vs. one from a set list validation would need to be included in the
Term::associate_with_object() code, based off the rules / features defined for
its parent Vocabulary. I'm not sure we've planned for the extensive exclusivity
you specify (a term is specific to a single object), but presumably that logic
would be accounted for in the same place - you cannot assocaite_with_object()
if the term is already associated with another object.
smime.p7s
Description: S/MIME cryptographic signature
