My understanding;

• "Refactor away..." exports as a page
• The above page wants to add a link to the last 4 children only

The simple way is to set the non-exporting containers to not export a page and then add ^childLinks^ to the page template for the main page. You can modify ^childLinks^ via its option inputs.  If you need greater HTML control you could use ^children^ instead using a second template which would emit just the HTML for the link. Both codes ignore non-exporting children. The method should (working from memory - not tested) still work if the last 4 items are aliases - the link will simply point to a different place.

If the output of a template is nothing, i.e. no text or mark-up at all, then no exported file is created even though the source note is being 'exported' (as opposed to export being suppressed via $HTMLDontExport). Thus if you wrap the entire contents of the template's code in an ^if()^ conditional statement, then a page is emitted on export oly if the condition is true.

I posted late last night and didn't have time to add in some links which might be useful. See:

• $HTMLDontExport controls whether a page export. It can be set via the UI using the HTML Inspector.
• ^childLinks^.
• ^children^.

Ok, this gets little more complex - in terms of construction - but is quite easy. You need a command that says "at this point insert data from notes meeting [criterion], laid out using [templatename]". If you don't give the second input (the template) you'll get the target notes' own default template output and you may end up nesting an HTML page in another which is an HTML coding error (even if it might render in a browser)

So let's start by assuming you've created an attribute called 'listing' which you'll used for the second part of the above. For example, something like:

Code:

<li>^linkTo(this)^</li> 

Now we can use a separate ^include()^ command for each of your two lists. As you want two discrete sub-group listings of items from the current page's children - and possibly not even all children - you can't use a single group designator like 'children'. [url=]find()[/url] is your friend here. In your main template:

Code:

...
<p>Listing of articles:</p>
<ul>
^include(find(inside(that)&$Prototype=="p_article"),"listing")^
</ul>
<p>Listing of videos:</p>
<ul>
^include(find(inside(that)&$Prototype=="p_video"),"listing")^
</ul>
... 

What is you'd like to use a different CSS class of the <li> element in each list. You could make a different version of the template (listing1, listing2, etc) for each list type. Of you could use an if clause in a single template:

Code:

<li class"^if($Prototype=="p_article")^green^else^red^endIf^"... 

The uses just one template but the condition gets long and complex if you've now say 4 different stylings.  Better to add a user string attribute $CSSClass and get each prototype to stop the appropriate CSS class value. Thus all notes using that prototype inherit that $CSSClass. Now you only need one listing:

Code:

<li class="^value($CSSClass)^">^linkTo(this)^</li> 

Note: time precludes me doing a full test of this, but I've linked to aTbRef listings on the codes which should explain syntax.

As noted in my last, I didn't have time to run the code posted but in the aTbRef reference to which I linked, you'll see I'd forgotten to enclose the find() action/query code in a ^value()^ tag. This works - in that it finds things:

^include(^value(find($Prototype == "p_funky"))^,"/Templates/HTML page/HTML item")^

But that filter finds every note with the 'p_funky' prototype (and every alias of those notes!). Also, doing tests using notes with names that are designator values designator is likely to only garner strange false results. So I re-named the container 'thingx' and the children 'x 1', 'x 2' and 'x 3'. I also added a root-level exporting note 'other note' that uses the 'p_funky' prototype - as we don't want to match out-of-container scope notes.

So, adding ^value()^ in the mix, what we probably want is something like:

Code:

^include(^value(find($Prototype == "p_funky"&inside($Name(that))))^,"/Templates/HTML page/HTML item")^ 

But (using v6.5.0) that doesn't work, though I don't know why. Knowing inside() has some not-easily-guessed logic quirks, I tried using descendedFrom($Name(that)) to see if using inside() where the issue. At which point the penny dropped.

Historically, ^include()^ was there to allow one note to import data from another, non-descendant, note of the one currently being processed. Likely it was never configured to do this sort of in-container-scope filtering - Eastgate can better answer that nuance. ^children()^ gives us all children, but not means to filter. But…

^children()^ can use a specified template for the import. So, we filter there, in the called template. Recall that if a template evaluates to nothing, nothing is returned (well some white-space may be but that's easy to tidy up once the bigger issue is resolved). Put this in the main page template:

^children("/Templates/HTML page/HTML item")^

Now, the 'HTML item' template becomes:

^if($Prototype == "p_funky")^<h2>^title^</h2>
^text
^children(/Templates/HTML page/HTML item)^
^endIf^

That works!  If you need different output for different page types, just put more conditions here. A single ^if^ with no 'else' here offers some or no output. An if/else structure could offer a choice of two outputs (or none).  If you've lots of choices and they're mutually exclusive, e.g. different prototype assignments, then you can just use lots of discrete ^if^ tests with not alternate as each tested note will only match one if test at most because a note can only have one prototype.

~~~~~~~
Template naming/references. You don't need to cite the full path to the template. I think that in the  built-in examples its a reflective hang-over from the days when templates were external text files and you had to tell TB where in the OS look Luckily that hassle is gone - all templates are in the TBX.

So, it's enough to use the title ($Name) of the template, assuming the name is unique in the whole TBX  - as templates are just a note with special characteristics.  If 'HTML item' is a unique name both these work:

^children("/Templates/HTML page/HTML item")^
^children("HTML item")^

The added quotes are now best practice but the legacy quote-less version still works. As can be seen, 'HTML item' is quite possibly a title one could use in a note, so a good idea is to use prefixes - as with your prototypes. I then to use a 't_' prefix, so would probably use 't_HTML_item' though tHTML item' would do just as well.  As long as it's a unique and valid name, choose a naming style that suits your style.

Sorry for the long post, but I hope the wider explanation will help folk bootstrap solving other export puzzles.  

My notes indicate that all expressions, such as find() within an ^include^ require a ^value^ wrapper. I can't get your first example to work, but it does if I use ^value()^. so, for me - using your test file - behaviour is consistent.

Behaviour of inside and descendedFrom is baked into the app, if you need that changed you need to write in as it's not user configurable.

Quote:

How else would Tinderbox know your context-specific export needs? Surely if a different behaviour is needed, it needs to be described somewhere?

Re ^value()^, I think you're drawing the wrong inference re find(). Re-read my notes on ^include()^

Note (emphasis added here by me):

Quote:

The 'bug', if such there is, is that your find($Name == "child 1") works when it should not.

This edge case doesn't surprise me. Reading between the lines, the role of ^value^ is to ensure the find() expression is fully evaluated before further use. As the (aTbRef) notes on ^include^ state, if the first input is a simple object or object designator then it's fine; anything more complex as a first input requires a ^value()^ call.

You should understand that (a) ^export^ code is a very old (15+ years) part of Tinderbox and predates action code and (b) ^include()^ has had functionality added over time. Originally, include - as per the Tinderbox Help - allowed a single object (note) to be included. Including more than one object, i.e. a group instead of an item was an improvement added in v5.9.2 and IIRC in response to supporting a rather complex export I was designing for another Tinderbox user. It needed find because different children needed handling different ways. I can't post from that project here as it was private consulting work.

Viewed in terms of how the feature has grown, it's not surprising - to me - that some use requires a little extra scaffolding compered with the basic original use.  Even if my memory failed me up-thread about ^value()^ the reference I cited was correct.

Quote:

Yes, but you're not doing that. your workflow is "find a collection of notes, and include them using different export mark-up depending on the nature of each child." It is your latter requirement which is causing you to need to write extra templates. From Tinderbox's perspective it doesn't matter how manny templates are needed as long as you connect them up correctly. So 'how many' is in part down to how export works and the rest to the users desire for more/fewer pieces. Although aTbref uses one big template for most pages, that was only an exercise in seeing if it were possible to replace the c.10 templates I had previously. I wouldn't argue the monolithic template is easier to use just because it's one item - it's certainly harder for a new user to deconstruct.

^include()^ need a second template argument if the target objects' own export template is not the one needed in this context.  If the target objects won't export as HTML pages in their own right, then you can set them to use the 'include' template code as their template (better, their prototype's template). Either way you still need to define each discrete differing set of HTML code.

If you're happy for the children to list in $OutlineOrder but want different mark-up (or no export) for each, then you can use ^children^ making sure you cite a template - or the children have a template - that resolves the differing export outcomes for each child. The latter has to encoded somewhere.

Quote:


Well okay. It's not like I had any way of knowing that. I'm just sharing what I observed.

Quote:


Not true. That was an addition we made later. But the original example document is quite clear: "find children that have a specific prototype, and include them."

That's the first step of my workflow. "Find a collection of notes [matching certain criteria] and include them."

A solution that appears to work

In any case, I may have found something simple that works. It relies on the fact that include() appears to look within the current note first. So I can create an agent that finds the notes I need, or simply create a container, and include that specific note. Here's an example document.

With any luck, this behavior will stay consistent on my larger doc...