SharePoint Development from a Documentation Perspective

Andrew May

Publisher: Using Tags to Store Custom Information (Part 1)

Publisher: Using Tags to Store Custom Information (Part 1)

  • Comments 4

Today I'm going to talk about the Tags collection, a feature in the Publisher object model that hasn't gotten a lot of notice, but is extremely useful when you examine it. (And I'm as guilty as anyone of ignoring it; one of the Publisher testers pointed out tags to me months ago, and it's taken this long for me to start playing around with them.)

Tags are, in essence, generic holding bins where you can store whatever information you want to persist with the publication. The Tags collection is a child of the Document, Page, and Shape objects, so you can save data at the publication, page, or individual shape level.

Each Tag object consists of two properties: a name, and a value. The Name property is simply a string that identifies the tag. The Name property of a Tag must be unique within a given Tags collection. For example, you can't have two Tag objects named "Creation Date" in a single Shape object, but multiple Shape objects could each have a single Tag object named that.

The Value property of a Tag object is where things get interesting. It's data type is Variant, which means it can store any data type except fixed-length strings. (For more information about the Variant data type, see this reference topic.) So you can store pretty much any kind of information you want, including user-defined types.

Here's another interesting aspect of tags: The Tags collection is one of the rare pieces of the Publisher object model that doesn't have a counterpart in the application's user interface. (The only other instance of this I can think of is WizardTags.) Tags are a totally programmatic feature: you can't get or set Tag objects except through code. So unless you explicitly expose them in the user interface (by displaying them in a dialog box, for example) or the user writes code to find them, the average user isn't going to be aware of them at all. Which makes them an ideal place to store information you don't want the average (that is, non-programming) user to have easy access to.

To add a Tag object, use the Tags.Add method, which takes the Tag object name and value as parameters:

ActiveDocument.Tags.Add "CreationDate", CStr(Now)

So what kind of information can you store in tags? Pretty much anything you want. Seriously, the more I play around with tags, the more ideas I get for how to use them. I'm in the process of implementing some of these ideas in code. I'll post code samples as I complete them. For now, consider the following example to get your mind thinking about how you could use Tags in your business processes:

Suppose you're creating publications for a number of projects. You might want to add a Tag object to each publication to identify which project it's for. So you add a Tag object, named for the project, that has an initial value of "Pending":

ActiveDocument.Tags.Add "Farble Project", "InProcess"

When the project is done, you change the value to "Complete". Then, you write a procedure that goes through your various work folders once a week and moves any publications where Tag.Value="Complete" to a 'Completed Projects' folder.

Here's the hierarchy of the Tags object model section:

In my next few entries, we'll look at examples using Tags at the publication, page, and shape levels. See you then.