Amazing wizardry with format(), a do() and .replace()!

I've attached a demo tbx showing a much less elegant and more verbose (but, for me, easier to replicate and in some ways possibly more flexible, e.g. can get a line break where needed) "loop" method, similar to that described here.

Three code notes do the work:

'cLoopInit' sets things up and uses MarkA's nifty method to exclude certain key attributes with replace().

Code:

$MyTempString=;$MyTempList=;$LoopCtr=0;
$MyExportSet=$KeyAttributes.replace("citeinessay|citetype|nickname","");
$LoopSize=$MyExportSet.size;
action($Text("cLoop")); 

'cLoop' uses the .at() operator with the loop counter attribute to cycle through the items in list of key attributes. For each key attribute that has a value in that note (the if(eval()) is testing to make sure it is not empty) a temporary string is populated with the attribute name and attribute value.  Then this temporary string is added to a temporary list.

Code:

if($LoopCtr<$LoopSize) {
$CurrListItem=$MyExportSet.at($LoopCtr);
if(eval('$'+$CurrListItem)){$MyTempString=$CurrListItem+"={"+eval('$'+$CurrListItem)+"}"}else{$MyTempString=;};
$MyTempList=$MyTempList+$MyTempString;
$LoopCtr=$LoopCtr+1;
action($Text("cLoop"));
}
else {
action($Text("cMakeReport"))
} 

'cMakeReport' formats the temporary list with line breaks, adds some stuff before and after that I understand BibTex needs, replaces some values, and places the result in $Text, from where it can be viewed and exported.  The effects can be seen dynamically by opening the 'test-reference' and inserting/changing values for the key attributes. (The text updates immediately if one File/Saves without closing the note.)

Code:

$Text="@"+$citetype+"{"+$nickname+",
";
$Text=$Text+$MyTempList.format(",\n");
$Text=$Text.replace("URL","howpublished");
$Text=$Text+"
}"; 

In practice one would probably want to add a "guard attribute" with conditional or some other mechanism so that the loop doesn't continually run. Here, I've got a stamp that can turn off the rule.

Some complications/questions:

1) Should TB always evaluate 'year' and 'month' as -1 and 6?  (see the eval() in 'cLoop') That's what I got for the values when I had the attribute names as 'year' and 'month' even when no values had been entered for those two attributes in the current note. I got around the problem by renaming the attributes 'byear' and 'bmonth' but then had to add the .replace() to 'cMakeReport' to change the names to what (presumably...I haven't used it) BibTex expects. (Am thinking problem may be because there should be an escaped $ within the second eval() but not sure how to do that).
Edited:
 

2) If had attributes 'byear' and 'bmonth' could these be replaced by 'year' and 'month' in one replace()?  I see aTbRef mentions multiple back-references with .replace() but don't know how that might work in this case.

As always, interested in suggestions/critique.

Quote:

Ah, hadn't thought of confusion with year() and month() action operators! Without parameters perhaps they default to -1 and 6.  Can now see need to prefix '$' in the expression.  Ended up using single quotes because double quotes were already used.

Quote:

That would be great!  Finally see a practical application for lowercase().

To make a few less moving parts, we can merge the 'make report' code with the loop, like so:

Code:

if($LoopCtr<$LoopSize) {
	$CurrListItem=$MyExportSet.at($LoopCtr);
	if(eval('$'+$CurrListItem)){
		$MyTempString=$CurrListItem.lowercase()+"={"+eval('$'+$CurrListItem)+"}"
	} else {
		$MyTempString=;
	};
	$MyTempList=$MyTempList+$MyTempString;
	$LoopCtr=$LoopCtr+1;
	action($Text("cLoop"));
} else {
	$MyExportString="@"+$CiteType+"{"+$NickName+",
";
	$MyExportString=$MyExportString+$MyTempList.format(",\n");
	$MyExportString=$MyExportString+"
}";
}
$MyExportString=;
$MyTempList=;
$MyExportSet=;
$MyTempString=;
$LoopCtr=;
$LoopSize=;
 

Now we've reset the in-loop and loop control variables at the end. We can't remove the last ^action^ call from the export template, as we can reset $MyExportString before we use it. The template is now:

Code:

^action(action($Text("cLoopInit")))^^value($MyExportString)^
^action($MyExportString=;)^  

Edited:

The outcome is exactly the same as in the last post, but we've one less code note, which I feel is a little tidier. As ever, there's more than one way...

Oops, edit made above!

Quote:


I think you answered the question. In this case, as we're doing export, it makes more sense to only run the code during export (open HTML view does the same). By the same token, there's no point in storing  temporary values used for the export process.  Were the data being used internally, it might be a different deal.  Also consider an agent action vs. per-note rules. Why? An agent can be turned off. Inefficiencies that won't show with a one or two note test may, with thousands of notes, slow up operations; there are no hard-and-fast metrics lest someone lask. Ergo it's best to make code as efficient as possible so scaling doesn't have undue effect. One good rule of thumb is to limit scope; don't apply a rule to 50 notes when only one really needs to use the code (e.g. prototypes). Conditional if() tests can also help block inappropriate running of longer sections of code - i.e. 100s of notes might run the test but only few meet the condition and run the main branch of code. The same concept applies to queries:

Worse:   $Color=="blue" & descendedFrom("Test")

Better:   descendedFrom("Test") & $Color=="blue"

Why is the latter better? The first test finds only those notes descended from a given container and only those notes are tested with the rest of the query. The first example tests $Color for every note. Inefficient!

Quote:


I think that speed/frequency is a pragmatic choice - the same CPU is providing cycles to run UI updates as doing code, etc.  There's a balance of application of effort. nothing sinister, I believe.

In my revised version, cLoopInit is called from the template.  The template is only evaluated if Export as HTML (full doc export) is called or a note's HTML view is opened. In the latter case this is necessary as it needs to show you the output code - i.e. the processed result of the template. In full export the call will be once per template, in HTML view it may occur repetitively whilst the view is open - changes affecting the output are detected. An exception in this context is that HTML view does not show the full result of $HTMLExportCommand as that command line is run on the output file from export - i.e. run on the code as seen in HTML view. In HTML view if that note is set to use an $HTMLExportCommand and if either the Preview or Export buttons are pushed then the code as seen in the code pane would be post-processed and thus different from the actual exported code.

By comparison, triggering this whole loop process in a Rule means it's firing every update cycle for every note using the Rule.  I think you'll agree that's more activity overall. Clearly, in a small test we won't see much impact but on a big file a Rule is probably a wasteful method if the loop is only needed for export purposes.

For non-export use, you could 'gate' the call to the looping code behind a Boolean as in: if($DoLoop){… That way, cLoopInit only gets called if $DoLoop is true. so the Rule might get run in many places but with little impact as $DoLoop would in most cases be false meaning the loop call code would not run.

Incidentally, if you wanted to use both internal and export method, then a further boolean could control, in the loop code 'else' branch whether $MyExportString is just send to export or whether it is also sent to $Text or some other String attribute for internal use.

There's no single right way - it depends what you're trying to do. The only central tenet is thinking about not running more code than needed more often than needed. The more complex the code the more getting it wrong may affect general performance.

Footnote - FWIW I'd still like to see TB get a List.loop() function that makes this more accessible to the general user who doesn't code and to whom loop counters, etc., mean nothing.

Edited:

Deprecation of ^action()^ has actually been removed as the difference in function from ^value()^ has become clearer - for the reasons you describe.  I'd already changed that but the old page was still on the website - I've checked and corrected the page.

How might a loop() look -assuming there is one? I think that's still an open field. I'm sure input is welcome.