1 reply [Last post]
btanner
Offline
Joined: 2010-04-13

Probably just a small oversight.

I have a generic container that has a title, a description, and then a list of objects (usually strings that I use for bullets). I wanted to refer to it through a shorthand variable, but the variable assignment leaves an empty paragraph in my document:
$codeReqs=theResponsibilitiesModel.getCodePlanRequirements()
$codeReqs.title
$codeReqs.description
- $codeReqs.entries[*].toString()

I can solve this problem by writing it this way:
$codeReqs=theResponsibilitiesModel.getCodePlanRequirements()$codeReqs.title
$codeReqs.description
- $codeReqs.entries[*].toString()

But, of course, $codeReqs.title is in H2, which means that whole line looks huge and ugly in my document. Not a deal breaker, but it hurts readability a lot.

On a related note, it seems crazy to me that Docmosis calls theResponsibilitiesModel.getCodePlanRequirements() 11 times in order to render that code. 11 times to create the title, description, and 6 bullets.

Do you guys really recreate the entire data structure for each item you pluck out of it? Compiling my large manuals takes about 60 seconds on a fast quad core workstation. Should I be creating caches of these objects and structures within my own code because you guys aren't?

For example, in my code, getCodePlanRequirements() goes to disk, reads a file, processes it line by line, and for each does a number of costly text substitutions (looping several times over the hundreds of variables I have defined looking for matches). Naturally I figured that would get called one time for every compile of the document. However, now it looks like it is getting called all the time, which means perhaps I should be creating cached copies of all such variables throughout my program and then clearing the caches between compiles. Is that right?

paulj
Offline
Joined: 2010-11-25
Variables and blank lines

The issue of set-variable fields leaving blank lines behind has been resolved with release 2.2.3.

As for the 11 lookups on your reflected code, the implementation uses a deferred lookup which means the variable(s) are evaluated when used rather than when set - leading to more calls than is really necessary. Improving this has been noted for a future enhancement.