Attribute-level relation key for keywords datatype

Saturday, 15 December 2007, 23:16
Categories: Random thoughts
Tags: keywords, keyword attribute, keyword, keywords datatype, tag cloud, meta tags, meta keywords, managed tags, solution

Using keyword attribute is a very convenient method of improving the site's navigation system and leading users to the content of their interest.

Limitations

If you're planning to use keywords attribute for anything that should behave as managed, then you shouldn't use the datatype for any other purpose within the same eZ Publish installation. Or, on physical level, you shouldn't have more than one keywords-datatype-based attribute per content class.

At this point keywords datatype stores all its values in one flat database model that does not provide any means of grouping or categorization on the attribute level (it is possible to fetch keywords based on the content class, but that's not exactly what's needed).

Example:
If in your article class definition you want to have two separate attributes for meta keywords and tag cloud tags respectively, then you should only choose keywords datatype for the tag cloud and another one, for example a text line, to collect data for meta tags. If you choose keywords datatype for both:

  • You will often find yourself making decisions whether place given phrase in the first, in the latter, or maybe both, which means terrible management with little control...
  • You will get duplicates in the content/keyword view as well as duplicate counts (tag cloud becoming less accurate),
  • Your keyword index (and database table) will grow for no particular reason.

That text line is perfectly indexable for search and as long as you don't require any logical operations on the collected data, then it fits most needs just fine.

One possible solution

Now, I've mentioned that it is possible to fetch keywords by content class(es), but that is an answer to "where" question rather than "what question". What if you want to have 5 keywords attributes in your content class, for 5 different purposes?

Solution seems quite simple. Keywords datatype could have an additional ID, that would make it possible to group keywords on attribute level. This could be simply an integer/string typed by the user when defining a content class, or it could easily become a drop-down list of labeled options, if an extremely simple mechanism/manager for managing keyword groups was implemented.

Comments

No comments yet
Log in or register to add a comment