Get tag quality in an expression

[wpmccormick]

I’m looking for a way to tell if a tag is enabled or disabled in an expression, and bind that to a property.

I want to control a button visibility based on the tag’s quality. If the tag quality is disabled, then not visible.

isGood doesn’t seem to work and I don’t see any way to get to the quality (in an expression) directly.

[WillMT10]

Not sure this is the best option but you could reference the tag Quality meta property directly:

{[default]path/to/tag.Quality}

[dkhayes117]

@WillMT10 suggestion seems to be the easiest method. Just use an expression binding then use the tag browser to select the tag’s quality meta-property, nothing else needed unless you need it as a boolean then

if({[default]path/to/tag.Quality} = 'Disabled',0,1)

[JordanCClark]

{[default]path/to/tag.Quality} != 'Disabled' would probably suffice.

[dkhayes117]

Syntactically shorter, but more confusing in my opinion

[wpmccormick]

thanks. So the complete expression that works is:

tag({template/tag/path}+’/some/sub/tag.Quality’) != ‘Disabled’

[WillMT10]

From one of the many @pturmel teachings, I’d recommend creating a custom property that is an indirect tag binding to {template/tag/path}+’/some/sub/tag.Quality’. Then change your expression to

{new_custom_property} != 'Disabled'

[wpmccormick]

Seems to make sense, not having having that hard-coded in an expression binding. But what problem/issue does that solve? Can you site a use case doing it one way and the other?

[WillMT10]

From that same thread I linked above:

@pturmel

When you use the tag() expression, it has to go get that value for any re-evaluation of that expression, including an actual tag value change. When you break it out to an indirect binding, that binding will only make a request when the path changes, and sits waiting just for tag changes otherwise. The expression will re-evaluate on the new tag property change, but other reevaluations will only grab the subscribed tag value. Much more efficient.

If you were to use tag() functions extensively, it can get A LOT more sluggish than using indirect tag bindings (learned this the hard way...).

[wpmccormick]

Thanks. Had I only followed your link I could have answered that myself. Thanks for being polite.

[nminchin]

Just note, in v8 the quality strings have changed. Disabled becomes Bad_Disabled

Undocumented changes when migrating from v7 to v8

Just some items I’ve found during v7 to v8 upgrades that may not be documented (some of them might be) and can cause hiccups (and quite a bit of work, relatively speaking!). The official guide to upgrading from IA is here. Tags: UDT v7 property UDTParentType has been renamed in v8 to TypeId Tag quality string values have changed. E.g. EDITED FOR 8.1.10 below 8.1.10 “Not Found” ==> “Bad_NotFound”; “Disabled” ==> “Bad_Disabled”; 8.1.10 and above “Bad_NotFound(Error description…)”, “Bad_ErrorC…

Also, IA have always recommended against using magic strings to compare quality, as you can see, they may be changed in future versions. Although there's no alternative at the moment in the expression language if you want to check for a specific quality. isGood({[default]path/to/tag}) should work, stealing Jordan's tag path from his post. Note: don't include the ".Quality" on the end, as the quality when reading the quality of a tag itself will always be good

[JordanCClark]

In v8, you actually get an Enabled property, going back to the OP.