dawn at dawnthots
May 2, 2011, 12:42 PM
Views: 1147
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
>
|
