I assume this relates to the deme export template code (for those without the demo):
^include(^value(find(inside("Test cell")&$SiblingOrder<11))^, ^value($PostListTemplate)^)^
The syntax for ^include^ is:
^include( item|group[, template] )^
First parameter: a list of one or more notes (either as $Name or $Path). It appears ^include^ doesn't (currently) accept group designators, so to pass a group of notes we need one of:
- a literal list e.g. "/animals/ant;/animals/bee;...etc".
find(query) that returns a list of paths (one or more items). N.B find does not de-dupe, so unlike an agent query you may need to filter out aliases.
a group designator (currently not supported for this operator)
Second parameter. An optional export template. If supplied, use the template to render contents from the list evaluated from the first parameter input. The template, is either
- A literal string with an export template (unique) $Name or full path if not unique.
- A string attribute storing an export template (unique) $Name or full path if not unique
A difference—and one only I spotted testing this issue—is that in the case of an attribute-stored template, for
^children($StringAttribute)^ the attribute is evaluated in the parent (calling) note whereas in
^include(find(query),$StringAttribute)^ the context of evaluation is each list item.
In the demo the find() method for the first parameter. Generally, simple queries return matches in $OutlineOrder, but this can't be assumed - especially with more complex queries (e.g. a query looking at the contents of an agent). If sort order is important, I believe, you can sort a find() within a query input. Lightly tested, the following tested in my demo file seemed to work to give a reverse outline sort:
find() doesn't de-dupe can mean
inside() gives unexpected results.
inside() doesn't match only the actual notes found in that container but also any note with an alias in that container. I've found that it is often more sensible to test the $Name (or $Path if not unique of the parent of the original). An alias will never match - unless alias and original are in the same container.
So, yes, but with all the various wrinkles outlined above.
Last point, if doing more than the most trivial use of action export code, these are good stylistic rules:
- Give prototype a consisten naming syle (a prefix character is best) ensuring they are never misteken for a normal content note. This aslo assumes the prototypes are not use as content, only patterns for such, and are best stored in the default
- Don't re-use Titles, i.e. $Name must be unique. If necessary, store the non-unique name in an attribute and use it for $DisplayName but have a unique value for name so queries work correctly
- The same goes for (export templates). If you use unique $Name then you can juse just the title and not clutter your code by using full paths. In current Tinderbox, you might was well add a built-in template to create the default
/Templates container and attendant
HTML page prototype.
- Do not use a forward-slash '/' or normal parentheses '(' and ')' in a $Name. Why? Because it tends to not get parsed properly either as a $Name or a container section of a $Path. This is especially troublesome when using action-code linking/unlinking codes. Use the same approach as above of having a 'safe' $Name and caching the real title in a string attribute which can then be used for display purposes. I hit this issue all the time when my notes are the title of academic papers.
Does that help?