This content has been marked as final. Show 10 replies
Why do you ask? Do you feel you may need more than a few?
Realistically, I believe there is no limit from the standpoint of how many you can create. However, I do believe there IS a limit to the size of the build expression. I think it's about 255 characters or so. As you might imagine, if you need to exclude a gob of tags via the expression, it behooves you to be brief with the names of the actual tags. The build expression often looks like this:
NOT taga AND NOT tagb AND NOT tagc AND NOT tagd
So if your tag names are long, like this:
NOT myverywonderfulbuildtaga AND NOT myverywonderfulbuildtagb AND NOT myverywonderfulbuildtagc
you won't be able to exclude nearly as many via the expression.
Hopefully this helps... Rick
I have a client who has a need to publish varying content for numerous agents and states; the deliverable is a guide for a large group of varying audiences. The combinations of tags will hopefully not get too complicated as they will mostly be includes rather than excludes. We're currently tossing around ways to keep the massive amount of content single-source. It may come down to a need to maintain separate systems and merge rather than use tags, but they'd rather not go that route. I was just wondering what kind of limit I might run into as we move ahead. I've used tags before, just not in a large quantity, so I am not sure of any limitations.
Thanks for your feedback.
I seem to recall that we tested the number of conditional tags on one of the betas, pretty sure we went over 100. But, you may find it hard to manage a project with lots of conditional tags. There is also a little anoying bug that hides a proportion of the conditional tag window, so long conditional tag names get cut off (this will hopefully be fixed in the next release), so don't use long names for conditional tags.
You are definitely doing the right thing tossing around ideas at this stage! Think about the include and exclude logic and ways to minimise the number tags at before it is too late. I managed one project with about 20 tags, one for each client without any problems - however, I needed to be very level headed and sober on shipping days ;-)
You promised not to tell anyone!
Just a word of caution:
Include/exclude strings can be problematic. You think you built them logically, but RH (sometimes) gets the output wrong. I wish I could be more specific on how it gets confused.
Be sure you test your approach on a skeletal structure before applying it to the live project.
If you plan to build print documentation from RH, test it there, too.
Do you know if there is any way to get around the 255 character limitation in the build expression? My client REALLY wants to keep all their content in one project ... and there are a massive amount of tags. So, naturally, I'm running into trouble with the character limitation.
You could rename the tags to shorten them.
A tag called ClientBwantsthis could become ClBwants.
If that strategy doesn't get you down to 255, you could convert to a number-letter code where Client B is 2, wants is w and x is exclude. "ClientBwants" is B2 and Bx substitutes for "ExcludethisfromClientBoutput."
It would take some time to set up, and maintenance could be difficult. But you say you have "a massive amount of tags."
If the structure will be fairly stable over time, you could simply start numbering at 1 and keep a printed decode list handy. Then your longest tag would be no more than 3? 4? digits. That's about as drastic a scheme I can imagine. How many are "a massive amount"?
Another approach is to find as many common factors as you can, and make a single tag work harder than covering a single state or client.
I guess I'm lucky. My most complex setup was for just three groups, where everyone got nearly everything, but some was for group A only (not B and C) and some was for everyone except group A. It needed just three tags and a relatively short string.
A math wizard maybe could tell you just how many terms a string could require, given the number of tags you're using, allowing for all possible combinations.
A three-character standard gets you 31 "AND" connectors (32 tags) in a string of 251. Substitute one "AND NOT" connector, and you've hit the ceiling.
Would it be possible to combine a targeted set of layouts in concert with your build tags?
That is, Layout 1 would only be produced with the same small amount of build tags, Layout 2 another small amount, etc. I'm not saying Rick's minimalist tag naming model shouldn't be used; I think you might implement a combination of short tags and different layouts.
Then there's also the programming solution: the developers would establish user/group permissioning to restrict the viewing of certain folders, etc.