Using content from Strings attributes in Prefix text

[4everJang]

Hello all you EDD experts out there,

I did not find this specific info in the struct app dev guide, so I am hoping someone else has figured this out at some point in time. Maybe this is trivial to programmers, but I am not one of them and also I don't know what the prefix definition string will allow. So all help is greatly appreciated.

In my structured framemaker EDD, I am using attributes to collect usage info. It would be nice to be able to use the Strings type attribute for this, instead of collating all the usage info into one single String type. But I need to use the content in a prefix string.

Prefix: used in: \t<$attribute[validity]>

If the validity attribute is of the Strings type and I enter multiple string values, only the first one shows up. How can I make all strings show in the prefix ?

Thanks in advance for the golden tip 🙂

Jang

[Russ Ward]

Jang,

Without testing this, my suspicion is that you are out of luck. How would FM know how to concatenate the strings? Would it use a single whitespace, or something different?

Given XML compatibility issues and other considerations such as the issue you have raised, I have personally stopped using the Strings attribute type. Is there a reason you need to use it? Could you just use a tokenized list within a single value?

Russ

[Van Kurtz]

Jang,

The individual strings in an attribute of type Strings are separated by carriage returns. But you are correct in that the $attribute building block shows only the first string, that is, the contents up to the first carriage return. To my knowledge, there is no way to show the whole set of string values.

The alternative is to separate the strings with a space character; however, the attribute type becomes String, not Strings. But in this case, the $attribute building block displays all the strings. The downside is that there is no way to distinguish the individual strings values, unless each value is a single word.

Van

[4everJang]

Hello Russ and Van,

I was kind of worried that I was crossing the limits of what FM EDDs can do. It is not a big deal - I can use the one string to store all values, as I have been doing so far. It just looks a little ugly when the string gets longer and the substrings do not wrap nicely. Of course going fully XML and XSLT etc would be another option but that is overkill for this particular client and they won't pay for that. Making the output a little nicer to look at is not a high priority, as this particular output is only shown in a catalogue of repository items to be used internally by my cient, i.e. it will never show in publications for users.

Thanks for confirming my intuition that I should stop searching for the holy grail...

Jang