Hi all. Not sure how best to describe this concept so I'm going to walk through a use case.
I'm looking for a way to make the external reference mechanism (importing other templates at run time) far more powerful.
I have a document that has many small sections (1/2 page to 5 pages each). These sections are conditional, some combination of them appears in each final document but it varies. It may technically be possible to get the ideas from here working with repeated sections but since the section structure varies considerably (number of paragraphs and their formatting), it seems much more complicated to handle this in that way.
Each section has some standard text, some custom text, and includes one or two worksheets (maintenance records). Each section also has a photo collection of 0-4 photos. The number of photos isn't known until runtime and will vary from section to section, but I want them all to be in the same part of the section, either 1-across, 2-across, ..., 4-across. Below is a description of my current method for solving the problem and a sketch of a better way if fields could have variable names and if variables could be passed into external references.
I have used [ ] instead of < > to get past your forum post formatter.
[[cs_SectionAlphaSystems]]
Alpha System
This is my alpha system text. It is hard coded in the main template.
The custom runtime text for this section: [[AlphaSystemsCustomField]].
[[ref:AlphaSystemsMaintenanceSheetOne.odt]]
[[ref:AlphaSystemsMaintenanceSheetTwo.odt]]
Photos
Note: So far everything above this has been easily achievable with straightforward docmosis. Here is the part I want to make easier.
===Current Photo System===
[[cs_{AlphaSystemPhotoCount='1'}]]
Table [1x1] [[bm_imgAlphaSystem1_1]]
[[es_{AlphaSystemPhotoCount='1'}]]
[[cs_{AlphaSystemPhotoCount='2'}]]
Table [1x2] [[bm_imgAlphaSystem1_2]] [[bm_imgAlphaSystem2_2]]
[[es_{AlphaSystemPhotoCount='2'}]]
[[cs_{AlphaSystemPhotoCount='3'}]]
Table [1x3] [[bm_imgAlphaSystem1_3]] [[bm_imgAlphaSystem2_3]] [[bm_imgAlphaSystem3_3]]
[[es_{AlphaSystemPhotoCount='3'}]]
[[cs_{AlphaSystemPhotoCount='4'}]]
Table [1x4] [[bm_imgAlphaSystem1_4]] [[bm_imgAlphaSystem2_4]] [[bm_imgAlphaSystem3_4]] [[bm_imgAlphaSystem4_4]]
[[es_{AlphaSystemPhotoCount='4'}]]
=== End Current Photo System ===
As you can see that is grossly unwieldly when the number of sections gets large. And of course there is so much repeated stuff in the template that changes to the overall design can be very laborious. Also it's hacky. Text fields can be repeated on open office, but photos apparently cannot. So in my Java code the following images labels map to the same image simply because I can't use the same label 4 times: bm_imgAlphaSystem1_1,bm_imgAlphaSystem1_2,bm_imgAlphaSystem1_3,bm_imgAlphaSystem1_4.
Ideally I'd like to call all four simply bm_imgAlphaSystem1, but that can't work.
Here is another solution. Please excuse the notation if Docmosis currently does parts of this and I get the notation wrong. I'll also only use the concept at the inner level here but if the procedure was in place it could be applied hierarchically to make this super concise.
=== Suggested Photo System ===
[[$thisSection='AlphaSystem']]
[[cs_{AlphaSystemPhotoCount='1'}]]
[[ref:SinglePhoto.odt{$thisSection}]]
[[es_{AlphaSystemPhotoCount='1'}]]
[[cs_{AlphaSystemPhotoCount='2'}]]
[[ref:TwoPhoto.odt{$thisSection}]]
[[es_{AlphaSystemPhotoCount='2'}]]
[[cs_{AlphaSystemPhotoCount='2'}]]
[[ref:ThreePhoto.odt{$thisSection}]]
[[es_{AlphaSystemPhotoCount='2'}]]
[[cs_{AlphaSystemPhotoCount='2'}]]
[[ref:FourPhoto.odt{$thisSection}]]
[[es_{AlphaSystemPhotoCount='2'}]]
Now, I won't go and describe each of the included docs, I'll just do TwoPhoto.odt for an example.
TwoPhoto.odt
------------
Table [1x2] [[bm_img${thisSection}1]] [[bm_img${thisSection}2]]
I'm sure you can see how useful this would be. I have to create my TwoPhoto.odt a single time and by changing it's formatting I can update every part of my documents where I have two photos side by side. Not only does it save time and make things more consistent, but it allows my master template (the one doing the including) to be streamlined.
The trick to getting this working is a)Passing variable names into external templates and b)Using variable names in field names. I don't know how hard this would be to do on your end, but it would make the external referencing system closer to how it works with MediaWiki, which allows you to create very complex documents from really useful re-usable pieces.
This probably would not be a minor change so I understand if it's not something right around the corner. I'd love to know if you guys have future plans for something like this though.
Just for fun I'll show the more concise thing you could do if this could be applied hierarchically:
=== Suggested Photo System Even More Advanced ===
[[$thisSection='AlphaSystem']]
[[ref:PhotoBank.odt{$thisSection}]]
PhotoBank.odt
--------------
[[cs_{${thisSection}PhotoCount='1'}]]
[[ref:SinglePhoto.odt{$thisSection}]]
[[es_{${thisSection}PhotoCount='1'}]]
[[cs_{${thisSection}PhotoCount='2'}]]
[[ref:TwoPhoto.odt{$thisSection}]]
[[es_{${thisSection}PhotoCount='2'}]]
... etc
In this example the photobank include goes down to a single line. Want to add the possibility for a 5th photo? Change PhotoBank.odt in one place and each section now has that capability.
Hello btanner.
Thanks for the detailed analysis and suggestions.
1) Template-variables SHOULD be visible to included templates so we are looking at this presently. It was always intended that the data visible from within the referenced template should be as the referenced template was within the referring template. That is, separating the template into separate pieces should not make a difference to data-provision.
Your concept of passing $thisSection to the sub-templates should not be necessary since the sub-templates already have visibility to the current DATA in the context of where it is included (just not variables). The meaning being that "this" is implicitly available to the sub-templates. When we determine what is happening with the template-variables, then all the information available to sub-templates will be the same as if the sub-template were literally in the main document.
2) Depending on how you want to layout your images, this is likely to be an ideal solution (and the principle applies to using templates in general):
i) create the "max-case" and lay it out how you wish. In your case, a 4-column single row table.
ii) place conditional column fields [[cc_{PhotoCount>1]] for column2, [[cc_{PhotoCount>2}]] for column3 etc. This will cause Docmosis to strip out the columns that don't meet the condition. The space left over is split among the remaining columns.
This way you have a single simple sub-template for presenting the images which lays them out evenly-spaced depending on the number of images to display.
This doesn't work if you also want to make the images different sizes when there's more space available. If that is the case, or you have other alignment/layout requirements then the way you have addressed it using conditional sections is correct.
We'll post back soon about the the variables issue.
Hey that image/table idea is a good one. I wanted to have the images be different sizes depending on how many there were but your suggestion is great, maybe I'll stick with 1 size. The table idea would simplify things a lot. Or maybe use two sizes with conditional rows to at least simplify the whole mess somewhat. Thanks.
Abou the variable stuff, it's possible that I just don't really understand it well enough. The demo examples and the manual are good but can't be exhaustive, and I haven't been able to piece together if there is a way to do what I want. I have been creating very small test examples to play with different syntax and have been unable to make things work.
I don't know if there actually is any problem with the template references right now, although you seem convinced there is.
If variables can be set to have values inside the template, and if those values can be changed, then I suppose I could make things work by setting up the data sources right. The system is quite powerful and rich and I'm not sure I'm making the best use of it. My naive brain was thinking that if I could do something like the following I'd be golden:
[[$thisSection='AlphaSystem']]
The field would be called AlphaSystem this time and the following would effectively call getValue('AlphaSystem') [[getValue('$thisSection')]]
[[$thisSection='BetaSystem']]
The field would be called BetaSystem this time and the following *identical field* would effectively call getValue('BetaSystem') [[getValue('$thisSection')]]
Should this sort of thing work? If so yeah I guess I can build from there and make fun things happen, eventually allowing me to have little reusable template files like I wanted. I feel like I tried hard to make this kind of thing work (even the first half) and failed miserably. Perhaps I had some syntax wrong and should try again. Any insights would be great.
I've been exploring this a bit so I thought I'd keep posting my progress and perhaps someone will chime in if they feel like enlightening me.
So it seems that the syntax to set a variable to a literal does not work. You cannot just do:
[[$myVar='stuff']]
That results in an error.
However, you could add a Java object with a method that just parrot's its input, and then you could do:
[[$myVar='dummyObject.parrotValue('stuff')]]
Now $myVar = 'stuff'.
What if I want to use this to look up images, like for example in an image field:
bm_dummyObject.getImageFor($myVar)
That does not work because there are no quotes. Next logical thing to try is:
bm_dummyObject.getImageFor('$myVar')
Unfortunately, this does not work either. This called dummyObject.getImageFor with parameter "myVar", which is obviously not the intention, what I want is for the parameter to be "stuff"
public String chooseImage(String imageChosen)
{
this.imageChosen = imageChosen;
return null;
}
iii) later, your call to getImage can make use of the setting in your Java object:
public InputStream getImage()
{
if ("stuff".equals(this.imageChosen)) {
// get my stuff image
} else {
// get some other image
}
}
Hope that helps. I've ended up making some concessions in my document design and embracing repeated sections, so this problem is less of a hassle now. I've given up some flexibility in my document's layout, but I've gained a much simpler template which is really nice to work with. I'm loving Docmosis more and more all the time btw, as I learn how to better use it.
However, there are some cases where I'd like better sort of control over images and this side effect trick you mentioned seems like a good way to proceed.
Thanks for all of the help. It's these little tricks and tips that really help your users appreciate the versatility of the software.
Earlier in this thread I got the idea that perhaps there were some issues with references that were to be worked out in an upcoming release of the software. Is this true, and if so, is it soon?
My document is really coming together, and it has some complicated structure. I've noticed some weird behaviour that comes up from time to time when trying to work with refLookup. Sometimes (but not always) if you call it certain ways, it will do weird things. Like for example I had a repeated section where each section was a refLookup to a List, where Pair has a value and key. Key was a label for the included file, and value was the actual file name (Both strings). So anyway in my repeated section I had something like:
[[refLookup:$this.value]]
This would give me weird errors about how certain methods were not available via reflection on Pair.class. The weird thing was that the methods that were not found were not used anywhere in the documents I was compiling, but did exist in totally different circumstances in completely separate documents. It was as if the templateStore was mixed up or something. Adding code to delete the templateStore to my clean/build cycle seems to have helped that problem.
I was having some other issues that were replaced by not using the Pair class described above, but just returning a list of strings and including with:
[[refLookup:$this.toString()]]
Now I'm facing an issue where my referenced documents have fields, but the fields are being filled with the name of the file instead of the variable value.
So for example I have a master document called Master.odt which in a refLookup includes NameDetails.odt, and NameDetails.odt has a field like [[MiddleName]]. [[MiddleName]] gets replaced with "NameDetails.odt" instead of whatever the middle name is.
These things are quite hard to isolate and I'm hoping maybe there is an update coming soon that will resolve all this.
Hello Brian.
It's good to see you are pushing the envelope.
The next release is due out this month (March) it has been delayed due to a lot of activity in the Docmosis realm in general. It contains many fixes and enhancements and some are related to the issues you've encountered with variables.
We will open a new support ticket with you to ask for an example of the problem you are having with regards to the last issue you've hit (template name rather than template being inserted). Expect an email from us and hopefully you are able to share your template with us so that we can confirm it is corrected by the next release.
Hello. Following on from the above, I have a template which needs to display two different adresses.
The following works:
- create a variable <<$address=clientAddress>>
- display the client's address fields e.g. <<$address.postcode>>
- reassign the variable <<$address=repairerAddress>>
- display the repairer's address fields using the same code e.g. <<$address.postcode>>
However, if I refactor by taking out the common address code into a subtemplate _address.odt and replace by <<ref:_address.odt>>, then it fails with "Variable not found "$address" Suggestion 1:Check the variable name Suggestion 2:Make sure there are no spaces in your field"
Being able to use template variables is rather essential, but it does not seem to work. I'm using version 2.2.2. Can you tell me please if I have done something wrong, or will this be fixed / implemented in another version?
Hello nboyd.
Your work is correct, the current version of Docmosis has a bug in which included templates don't see variables set in the parent. Brian helped us to identify this issue.
The problem has been corrected and is included in the release due this week.
Docmosis 2.2.3 has just been released.
This provides fixes to variables in referenced templates. Head over to the releases for more information.