The Metadata Plugin Metadata Management for Manila

Site last updated 2/24/2006; 12:33:21 PM

Home Why Features FAQ Updates Documentation Download Developers Bugs Feedback Discuss Planned Features				Built-In Meta Types With version 1.83, the Metadata Plugin now handles built-in meta types. This feature is targeted at people who know what the contents of the message table are. What are built-in meta types? You'll recall our discussion of Manila's message table. This is where Manila stores the data for each message. A typical message table looks like this: This message happens to also be a news item. One use of built-in meta types would be to change the author of a message. Look at the screenshot above. See that the member (i.e., who created the message) is set to jvandyk@iastate.edu? What if we wanted to change it to skippy@doodle.com? We'd go to the Managing Meta Types page by clicking the metaData link on the Editors Only bar. Then we'd add a meta type called member. Here's a sample screenshot for the Manage Meta Types page: After we'd added the member meta type, we'd be able to change that value from our Edit This Page form as simply as any other metadata value: Note several things here in the Manage Meta Types screenshot, above: Built-in meta types appear in green We chose not to include them in the HEAD element of our pages (what use do you have for including ctReads -- that is, the number of times this page has been viewed -- in the HEAD of your HTML document?) We did not index ctReads. It's stupid to index ctReads. In fact, it's impossible. ctReads changes all the time as people look at your pages. Keeping up an index would take a tremendous amount of resources. Also, what would be the point? Just so you can answer the question, how many pages have been looked at 7 times today? The situation is different with member, since a legitimate question is, Show me all the articles authored by skippy@doodle.com. So it's not always wise to index built-in meta types. But sometimes it's great. Set up a built-in meta type for newsItem.department and you're in business. You can say, show me the 50 most recent news items in the Dancing department. You might be tempted to add the built-in meta type body and turn on indexing. That would be foolish, because the entire body of the message is one value. Your index will swell like a hippopotamus in a yellowjacket nest. If you want people to be able to search through the body of your messages, use the search engine; that's what it's there for. Update: with version 2.0 of the Metadata Plugin, you can set the type of indexing to Text on the Managing Meta Types page. This means that you can index the built-in meta type body, since text indexing splits up the body into multiple words (i.e., values) instead of one huge value. Whether you use this or Frontier's search engine will depend on your specific situation. Other Notes Subject is a special case. Don't use it. It will not be indexed. You can use the {title} macro and Macro Expansion if you need to use Subject. msgNum is the key to the message's identity. Don't mess with it. Yes, you could hose your Manila site by doing something dumb like setting msgNum to 0. You have been warned. Built-in meta types don't show up when you're creating a new message, story or news item. That's because they haven't been defined yet. When you go back and edit, they'll be there. With version 2.14 and later, ctReads is decremented if a contributing or managing editor views the page. Manila increments it, we decrement it. The net effect is that ctReads does not change if a CE or ME views the page. This avoids artificially inflating hitcounts. Comments...