
dawn at dawnthots
May 2, 2011, 12:42 PM
Post #8 of 9
(1146 views)
Permalink
|
OK so last week Greg and I did look at keywords again. What I wanted to do - make new 'keyword collections' that could be added to a story element - might require adding a table and changing some other core functionality in Bricolage. >> my $memb_coll = $get_memb_coll->($self) for instance, is a vestigial organ from an earlier version of Bricolage. David rewrote the way keywords work somewhere along the way. If people are interested I could post diagrams of how I imagine the keyword collection interface looking / working - in case you like the idea and a few of us could work on it for another release. Anyway in the meantime - Greg suggested a very good way to get the functionality I need, use colons in the keyword fields to represent heirachy. For example, I need three keyword collections on my site, Location, ArtForm, Description So the first time I add keywords to my story "Murder on the Green Line" I add the following, clicking ADD each time. Location : Danforth Location : Toronto Location : Subway ArtForm : Murder Mystery ArtForm : Mystery ArtForm : Thriller Description : Suspense Description : Municipal Politics Description : Subway Rats Greg writes a hack to my install of Bricolage that creates a new method say $keyword->get_hierarchy('1'), which searches for' : ' and returns the text before the : as the first item in the hierarchy. Maybe $keyword->get_hierarchy('2') does a search for the child term? So in my story templates I could do a search for all keywords and list them by parent, or only look for stories that have a parent keyword that matches 'Location' (and then plot them on an interactive map). Something like that. Greg want to correct and clarify? Would anybody else see a use for this in their installations? Dawn On 2011-04-20, at 10:49 PM, David E. Wheeler wrote: > On Apr 20, 2011, at 7:13 PM, Dawn Buie wrote: > >> Yes you said that today on IRC. Greg and I looked at keyword groups in the API and a solution didn't leap out at us. >> >> http://www.bricolagecms.org/docs/devel/api/Bric/Util/Grp/Keyword.html >> http://www.bricolagecms.org/docs/devel/api/Bric/Util/Grp.html >> >> So would we make a parent group for the keyword group? Could you have groups of keywords that have groups of child keywords? >> >> my $parent_id = $grp->get_parent_id; >> $grp = $grp->set_parent_id($parent_id); > > I was going to say “no,” but now I'll say “maybe.” I’m not sure the parent_id stuff is actually used. I think it was included in the original design of the API and never used. Might work. I don’t know. > >> Or what is a member collection? It's a private method. Should we use that? > > A collection is just an abstract way of grouping things together. So yes, maybe you’d want to create a collection subclass instead of a group subclass. In fact, I’d say that’s probably the way to go (I forgot all about collections). > >> my $memb_coll = $get_memb_coll->($self) >> Returns the collection of members for this group. The collection is a Bric::Util::Coll::Member object. See that class and its parent, Bric::Util::Coll, for interface details. > > Yeah, but you can use collections directly in the Asset class and ignore groups, I think. I’d have to look at the API again to see how it works, but I believe there are other parts of the API that use collections…Ah, yes, Contacts are managed as collections. IIRC, there is a collection object for contacts associated with the Person class. No Grp required. > >> Or woud you uses classes of the keyword groups? >> >> my $class_id = Bric::Util::Grp::Keyword->get_class_id; >> Returns the Bric::Util::Class object ID representing this class. > > That’s what I was saying initially, but now I think using a collection subclass (for which you’d have to add a table, IIRC), is a better idea. > >> I don't dig into the guts of Bricolage normally so I don't know what the first step would be. > > Just lots of poking, really. The code is more important to read than the docs, as the docs are written more for templating and less for application design. > > Best, > > David >
|