News:IMPORTANT MESSAGE! This forum has now been replaced by a new forum at http://forum.eastgate.com and no further posting or member registration is allowed. The forum is still accessible via read-only access for reference purposes. If you wish to discuss content here, please use the new forum. N.B. - posting in the new forum requires a fresh registration in the new forum (sorry - member data can't be ported).

I don't remember whether exportedString can accept a group designator, or if it’s limited to a single note. The latter was my intent when I wrote it! But it could be generalized without too much pain, I think.

Easy way to test this yourself: replace the complicated "collect" and "find" expressions with a simple list.

First, try the conventional case:

exportedString(/container/example,template) <- try this first

Next, a list.

exportedString(/thing1;/thing2,template) <- try this next

If you can export a list, then you simply need to build the list with find(). If this doesn't work, email info@eastgate.com and tell us more about what you're doing and why.

My notes have exportedString() as using single item scope. I'd always thought of this operator as a way of transforming data inside a TBX using export code. Although using export code directly within action code is now deprecated, this method does so at arms' length as the export code is in a template (or supplied as a parameter). In other words, it was an internal transform powered by export code. That said there's no reason it can't then be used for export as per your method.

Later edit: re-testing in v5.12.0, it appears exportedString is indeed limited to a single item, rather than either a single item or a list. Judging by the preceding post that limitation may get fixed in due course.

Whatever, in v5.9.2+, ^include()^ was improved to support group scope - i.e. more than one item, in list form. I recall the genesis of this was the export template coding for Ted Goranson's blog. The right column of the latter has lots of per month listings made with multiple ^include()^ calls using a list which is (re-)populated immediately before each include : an ^action()^ wrapper around an action code to seed the include's list from a find() or collect_if().

Note I've altered your collected attribute from $Name to $Path to help disambiguate info. $Path's longer, but you never actually see the textual values anyway.

As collect_if() by default returns a list of $Path of matched notes, I'd make the include group a Set and not a List type of attribute as a Set will automatically de-dupe the list for you (should dupe matches occur).

Note too that $IncludeSet is reset after the include so we don't get query result data hanging around in the reference. You don't have to even set the list in the template via ^action()^. But why might you do so? Because the method scales, here we list Tasks A, B and C and separate dynamically calculated group includes - all within a single template:

Without the ^action^ calls within the context of the template you wouldn't be able to repopulate each includes different group listing. You don't need to reset the $IncludeSet at the start of the run as the '=' assignment overwrites all existing list date (whereas $IncludeSet = $IncludeSet + .... would add to it). Instead, you just clean up after the last include.