Mailing List Archive

On Apr 20, 2011, at 12:57 PM, Dawn Buie wrote:

> I could see a way to hack bricolage to do this for a client - but would it be of any interest to the group to have it added as a feature to bricolage?
>
> Also - does anyone see a better way to do this job?

If it was a feature, I wouldn't use categories to do it, but keyword groups.

Best,

David

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);

Or what is a member collection? It's a private method. Should we use that?

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.


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.

I don't dig into the guts of Bricolage normally so I don't know what the first step would be.

Dawn



On 2011-04-20, at 7:09 PM, David E. Wheeler wrote:

> On Apr 20, 2011, at 12:57 PM, Dawn Buie wrote:
>
>> I could see a way to hack bricolage to do this for a client - but would it be of any interest to the group to have it added as a feature to bricolage?
>>
>> Also - does anyone see a better way to do this job?
>
> If it was a feature, I wouldn't use categories to do it, but keyword groups.
>
> Best,
>
> David
>

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

thanks David

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
>

Hi,
I also wanted to implement site "tags" this way: to use categories for some predeclared "keywords".
Keywords are not categories, essentially. The example Dawn gave here is clearly a classification,
and I would say it's better to use categories. Keywords normally are flat, not hierarchical,
if my understanding is right.

Perhaps a category could have a type defined, to figure out if it goes into navigation menu
or not. I already miss a category order number to sort menu slots, and I use one ad keyword for this.
Is there any salt in this? :)

Regards, Zdravko



Dawn Buie wrote:
> Hi all,
>
> I'm interested in allowing a clients to create more than one groupings of keywords in a story.
>
> So instead of the current default keyword section at the bottom of all media and stories - there could be multiple stacked keyword forms. So 3 keyword groups could be called for instance Minerals, Vegetables and Fruit. The user could, from the story, add salt to the Mineral keyword group, and orange to the Fruit keyword group. Let's called them taxonomies.
>
> One way to potentially do this is to create a category /taxonomy/ - and all children categories of taxonomy are the taxonomy terms, so:
>
> /taxonomy/minerals/
> /taxonomy/vegetables/
> /taxonomy/fruit/
>

On 2011-04-21, at 1:32 AM, Zdravko Balorda wrote:

> Hi,
> I also wanted to implement site "tags" this way: to use categories for some predeclared "keywords".
> Keywords are not categories, essentially. The example Dawn gave here is clearly a classification,
> and I would say it's better to use categories. Keywords normally are flat, not hierarchical,
> if my understanding is right.

Except I want my users to be able to add/remove keywords on the fly. They can't do that with categories which become part of the URL.
>
> Perhaps a category could have a type defined, to figure out if it goes into navigation menu
> or not. I already miss a category order number to sort menu slots, and I use one ad keyword for this.
> Is there any salt in this? :)

I don't think it's very salty, no. Well who knows.

But I think Drupal has a 'weighted' items concept to allow you to make list items tend toward the top or bottom of that list.

Dawn

>
> Regards, Zdravko
>
>
>
> Dawn Buie wrote:
>> Hi all,
>> I'm interested in allowing a clients to create more than one groupings of keywords in a story.
>> So instead of the current default keyword section at the bottom of all media and stories - there could be multiple stacked keyword forms. So 3 keyword groups could be called for instance Minerals, Vegetables and Fruit. The user could, from the story, add salt to the Mineral keyword group, and orange to the Fruit keyword group. Let's called them taxonomies.
>> One way to potentially do this is to create a category /taxonomy/ - and all children categories of taxonomy are the taxonomy terms, so:
>> /taxonomy/minerals/
>> /taxonomy/vegetables/
>> /taxonomy/fruit/
>

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
>

On May 2, 2011, at 12:42 PM, Dawn Buie wrote:

> 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.

I think that would better help me to understand what it is you're trying to achieve.

> 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?

Hrm. So the point of a keyword hierarchy is so that you can be selective about what keywords you use in a template?

I'm sure I'm just being dense here…

Best,

David