So first things first, No John, that’s not forwards that’s backwards
- and unfortunately that approach will not work.
For reasons I’ll get into below, you’ll want to grab this morning’s builds of xFiles (4.35) and Reflection (1.31).
This answer is in 2 parts; first the simple version, then the longer version where v can be of undetermined length.
your original code would work with these structures;
root Group,Name('root')
version STRING(255),Name('version | attribute')
system &pQueueType,Name('system | queue | RowName(p)')
user &pQueueType,Name('user | queue | RowName(p)')
End
pQueueType Queue,Type,Name('p | RowName(p)')
n STRING(255),Name('n | attribute')
c STRING(255),Name('c | attribute')
v &vQueueType,Name('v | queue | RowName(v) | XmlName()')
End
vQueueType Queue,Type,Name('v')
v String(255),Name('|')
End
This mostly follows Layout 4, but with a wrinkle, so I’ve added Layout 5 to the docs to cover it.
Your next requirement was to make v into a StringTheory object so as to allow for unlimited length. That’s straight-forward enough;
root Group,Name('root')
version STRING(255),Name('version | attribute')
system &pQueueType,Name('system | queue | RowName(p)')
user &pQueueType,Name('user | queue | RowName(p)')
End
pQueueType Queue,Type,Name('p | RowName(p)')
n STRING(255),Name('n | attribute')
c STRING(255),Name('c | attribute')
v &vQueueType,Name('v | queue | RowName(v) | XmlName()')
End
vQueueType Queue,Type,Name('v')
v &StringTheory,Name('| StringTheory')
End
The only change there is in the declaration of the second v.
This though caused a wrinkle, because Reflection optimised blank field names away from some methods (which it mustn’t do) and also xFiles optimised setting fields with blank names (which it mustn’t do). Hence the updates to both xFiles and Reflection to support this case.
Your code to view the data needs to be upated to match, but I think you’ve got a handle on that.