On Oct 17, 10:09 pm, Chris Meller <[email protected]> wrote: > On Oct 16, 2010, at 7:01 PM, Owen Winkler wrote: > > <snip>
> > 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. > Vocabulary::add_term() are two points at which hierarchical details are dealt with in the current code, especially add_term(). Looking at the code ( https://trac.habariproject.org/habari/browser/trunk/htdocs/system/classes/vocabulary.php#L305 ), you can see that it is fairly complex and would be difficult to get correct. I would rather have this in core code than in classes using the code. Currently, as best I know, none of the other default features are enforced. Vocabulary has an odd place. First, a vocabulary is a thing in itself. It has a name, it has innate behaviors. At the same time, if not an actual container, it is a controller of the terms that live in that vocabulary. Each of the terms in the vocabulary can be reasonably expected to know about it's own properties and have some contact with its neighbors in the vocabulary, but not the properties of the vocabulary as a whole. Only the vocabulary can know that. Thus, the current design in which terms are added to, and removed from, the vocabulary through methods of the vocabulary. If it were possible, I wouldn't think the CRUD methods of Term would be publicly available, but only to the term itself and the vocabulary it belongs to. As it is, they are public and thus subject to careful handling lest actions on them break the vocabulary. While I don't know if it is true, it seems that most of the design of Vocabulary and Term as they now exist stem from those basic assumptions. Like all designs, it can be improved. Tag and Tags probably illustrate this. In part their designs were based on those of Post and Posts, as well as the old Tag and Tags classes. They came out fairly heavy. In many cases the methods within them are convenience methods that aren't completely necessary to the usage of the classes. The usage in Post illustrates that they do have problems. I'm not against a redesign of the structure, though right now I'd like to get 0.7 out the door. :) I do think we should look long and hard at a design that takes Term from being the relatively dumb object it is now to one that tries to play the role of the vocabulary to which it belongs. <snip> Rick -- 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
