Output job properties

On the Output job properties tab, which is present when you have selected a new or existing output job for a data source in an application in the Application browser, you specify the output format (adapl and/or Word templates, or adapl and/or XSLT stylesheets or Excel templates for printing) that must be available from within the current data source. All the output jobs that you specify for a data source will be listed in the Output formats dialog in Axiell Collections.
Printing from Axiell Collections is different from Adlib for Windows. For an Adlib for Windows output job you could have used an XSLT stylesheet, an adapl, a Word template (.dot or .dotx), a combination of adapl and Word template or a combination of adapl and XSLT stylesheet. Axiell Collections however, does not support Word template output formats with the .dot or .dotx extension, but it does support Word templates with the .docx extension, it supports output formats which have been specified as a combination of an adapl and a .docx template, it supports Excel .xlsx templates (from 1.16) and it also supports XSLT stylesheets as output formats and XSLT+adapl output formats, the latter even for the Raw template type. Note that XSLT stylesheets are not 100% compatible between Adlib and Collections. And Collections 1.10 and up also support adapl-only output adapls using print and output statements to print stuff, using the Custom Template type option (see below).
Usually, old .dot and .dotx templates can be converted to .docx templates fairly easily: our Helpdesk can provide support if necessary.

Click here for information on how to edit properties in general. And click here to read about how to manage objects in the tree view in the Application browser. On the current tab you'll find the following settings:

Adapl

If you want to use a model or custom adapl for this output format, then select the desired ADAPL procedure on your system. You can also type the path and name of the adapl yourself. Do not enter an extension.

With an adapl you can process any data and print the results as a PDF* (Collections only) or plain text (in Collections or Adlib) using PRINT and OUTPUT statements) or you can combine an adapl without PRINT and OUTPUT statements with a Word template or an XSLT stylesheet as you see fit: in the latter case, the adapl is often used to pre-process data.

A Word template can either be called from within the adapl (using the WORDCREATEDOCUMENT function which can be used in Collections too, or the WORDCREATELABELS or WORDPRINTDOCUMENT functions) or it can be called automatically by Adlib/Axiell Collections after the adapl has finished running for a marked record (by using the Template settings below). Which option to use, depends on what you want to achieve. The second option is the only one if you want to print to a label template (in Collections and Adlib), while the first option may be the only option if you want to collect data from more than one record before printing to the template. If you call the template from the adapl, you control the moment and arguments of the call, while letting Collections or Adlib do the call just transports all relevant data to the template after each processed record.

If you use a Word template which has been set up in the properties below in combination with this adapl, you probably want to transport some collected or altered data from the adapl to the template. To the template, tags from the currently processed record are available by default (including linked fields and merged-in fields) and referenced in the template like so: <<tag>> (where you replace tag by an actual field tag). If you want you can use your own adapl to change one or more values in tags from the processed record easily: the changes will only end up in the output, the processed record remains unaltered. Suppose your object record contains the repeatable tag VV (creator) in which names appear in the format last name, first name, but you want to print only the first occurrence and you want it in the format first name last name. The following line of code switches last and first name and puts it in the first occurrence of VV:
VV[1] = name$(VV[1])
By including the field reference <<VV[1]>> in your Word template, the altered data will get printed for each marked record in the result set.

Now imagine a more complex case, where the user wants to mark multiple records and for each of the records some data from the record must be printed in a table (click here for more information about that), but after processing the last record the total insured sum must be printed. So we need to know when we're at the last record and we need a variable that stays in memory (to contain the increasing sum) during every run of the adapl (the adapl is run for every marked record).
A number of reserved (system) variables (that you don't need to declare) are always at your disposal when an adapl is run. &I and &B are useful for tracking progress through the result set: &I contains the sequential number of the currently processed record (the first being 1) while &B[1] contains the total number of records in the result set. So in the adapl you can state (usually right before the end of the adapl):

if (&I = &B[1]) {
 /* print my total insurance sum
}

to have that print code only executed for the last record.
Now we need a variable to stay in memory. We can use a Windows environment (system) variable for this purpose, because normal, declared variables or FACS tags won't stay in memory and tags from the currently processed record will get new content with the next processed record. ADAPL offers the setvar() and getvar() functions to store and retrieve values in and from such variables. So for the first record you can store the value '0' in a new environment variable and for each processed record you can add the value from the relevant field, insurance.value (VY) in this example, while for the last record you can put the final value in a FACS tag which is referenced in the Word template.
Values stored in an enviroment variable or FACS tag are always strings (text). So before we can do calculations with such a value we must transform it into a numerical value using the VAL function (by also using the INT function you could even further transform it to an integer, but we don't need that now).
Also note that we must choose a unused tag from the last processed record or a tag from a FACS declaration to store the final sum value in, because otherwise it can't be transported to the Word template. It's best to usually pick a repeatable, long text field (with a length of zero), since a text field can contain any type of value, but you can also pick a numerical field if you know you're only storing numerical values in it or a date field for dates. Using an otherwise not printed tag from the last processed record is a quick solution but as a good habit it is probably better to always use a DUMMY FACS declaration. For Collections you should use existing field tags (as defined in the relevant .inf) in that FACS declaration. We usually call that FACS database DUMMY, but any other name is fine too. It can even point to the same database from which we're printing records. The opened FACS database will exist as a separate instance so it won't interfere with the data from the printed records. So in pricinple you could print tag BE (description) from each processed record as well as store the insurance sum value in tag BE in the DUMMY FACS database.
If we choose BE in a DUMMY FACS database to contain the last sum, then the Word template needs to contain the field reference <<DUMMY+BE>>. The full adapl will look as follows:

* My insurance sum adapl
fdstart DUMMY '..\data+collect'
 %0 is DUM_priref
 BE is DUM_printed_sum
fdend

open DUMMY noreset
if (&E){
 errorm 'Error opening database DUMMY, error code is  ' + &E
 end
}

numeric incrementedvalue

if (&I = 1) {
 setvar('totalvalue', '0')
}

if (VY[1] <> '') {
  incrementedvalue = (val(getvar('totalvalue')) + val(VY[1]))
  setvar('totalvalue', incrementedvalue)
}

if (&I = &B[1]) {
 DUM_printed_sum = getvar('totalvalue')       /* assign my total insurance sum to FACS variable
}

end

The Word template could look like this:

Note that the <<[StartRecordList]>> and <<[EndRecordList]>> parameters make sure that every processed (marked) record ends up in its own row in the table.

In yet a different type of adapl+template output format where you would only like to print from a single marked record, like a loan or assessment record and include data from all of its linked object records, you don't need environment variables: you can use normal, declared variables for sums and other collected data and use FACS to retrieve data from all linked objects (as far as that data isn't visible in the processed record yet, on the linked objects screen) and store it in occurrences of DUMMY FACS tags. See the example adapl below:

* This adapl is part of an output format which must be executed for a single, marked assessment record.
* It reads all linked object records and collects their data in a DUMMY FACS buffer
* We'll get our object data from a COLLECT FACS buffer

fdstart COLLECT '..\data+collect'
 %0 is COL_priref
 IN is COL_objectnumber
 OB is COL_objectname
 BE is COL_description
 DI is COL_dimensiontype
 WA is COL_dimensionvalue
fdend

* we'll use a DUMMY FACS buffer to store the data from multiple linked object records
fdstart DUMMY '..\data+collect'
 %0 is DUM_priref
 IN is DUM_objectnumber
 OB is DUM_objectname
 BE is DUM_description
 DI is DUM_dimensiontype
 WA is DUM_dimensionvalue
fdend

open COLLECT
if (&E){
 errorm 'Error opening database COLLECT, error code is  ' + &E
 end
}

open DUMMY
if (&E){
 errorm 'Error opening database DUMMY, error code is  ' + &E
 end
}

clear DUMMY

integer occs, i

i = 1                                /* to be used as the current occurrence number of
                         /* the repeated Object number group on the Linked objects screen
occs = repcnt(IN)        /* count number of object records linked to currently processed
                         /* assessment record

while (i <= occs) {          /* repeat as many times as there are linked objects
 read COLLECT using COL_objectnumber = IN[i]        /* since the object number is unique
                                 /* we can read the collect record using this number from occ i
   if (&E = 0) {                /* if the read was successful, fill occurrence i of the DUMMY FACS
                                 /* field aliases with data from the collect record that was read
         DUM_objectname[i] = COL_objectname
         DUM_description[i] = COL_description
         DUM_dimensiontype[i] = COL_dimensiontype
         DUM_dimensionvalue[i] = COL_dimensionvalue
 }
   i = i + 1
}

end

An example of a matching Word template would be:

Note that here, the <<[StartRecordList]>> and <<[EndRecordList]>> parameters must not be included because we're only printing a single marked record. Every occurrence of the DUMMY tags together (one linked object per occurrence) will end up in its own row in this table.

Note that for Adlib for Windows, the tags used in an adapl or in a FACS declaration didn't need to have been defined in the .inf per se, as long as they didn't interfere with the printed data, so you could have used non-existing, temporary tags in a FACS declaration like:

fdstart DUMMY '../data+document'         /* dummy database
Q1
Q2
Q3
fdend

or even without declaring them at all. A simple assignment like Q4 = 'my text' would store the string (of any length) in tag Q4 even if Q4 hadn't been defined in the .inf or in a FACS declaration. The template reference could then simple be <<Q4>>. Q4 could even have occurrences. However, for Adlib too it was better to only use tags defined in an .inf because when someone were to add new fields to an .inf in the future, he or she wouldn't know that certain new tags could be in use in output adapls already, possibly corrupting the output if the adapl hadn't been written well. Another issue might have been that in Adlib for Windows undefined tags could unintentionally be written to a record via a FACS WRITE in the output adapl, adding data to the record that shouldn't be in there. Trying to write an undefined tag to a record in Axiell Collections would produce an error message, because Collections is more strict in this matter.

Further note that you shouldn't use <tag>=null assignments in the adapl if the tag is part of a dummy FACS database: this causes errors when printing to a Word template. Instead, use <tag>='' to assign an empty value.

The combination of adapl and XSLT stylesheet can be useful for the situation in which you'd like to preprocess data from the currently processed record before the stylesheet takes over. When you program the adapl you don't have to take into account that the stylesheet will receive the record data as XML: the stylesheet can access the record data via the English field names. For Collections you must define your temporary fields in de database first though. (In Adlib the stylesheet also had access to temporary tags used in the adapl, via the two-letter tag names themselves.) The stylesheet itself typically converts the Collections/Adlib XML to HTML. An example of a useful combination of adapl and XSLT is when you like to create an output format which collects statistical data and prints it to a table or graph. The statistical data over a range of records can be collected by using FACS in the adapl, so that the user only needs to mark a single record, or just a few records, after which for each of those records an appropriate algorithm searches other records to collect and compound the desired data: the number of objects found underneath a selected location and its sub locations, for example. For application in Collections you'd put this data in (occurrences of) tags of temporary fields that you defined in the database first. (For Adlib, any compounded data would have to be put in (occurrences of) undeclared two-letter tags, which could then be read by the XSLT stylesheet.)

* PDF output through adapl-only output formats is limited to left-to-right languages. Languages like Arabic cannot yet be created even with Unicode fonts. Also Chinese, Japanese and Korean languages are not supported.) Instead, try using a Word template or XSLT stylesheet to create the output format: these methods do support the mentioned languages.

Template path

For this property you may select a Word template with the .docx extension (Axiell Collections only supports .docx files while Adlib for Windows accepted .dot, .dotx and .docx files) or an Excel template with the .xlsx extension on your system to set up as an output format. (In the Select a document template window, which opens after clicking the ... button behind this option, select All files in the drop-down list behind the File name entry box to be able to see .docx templates as well: the default Document template option only displays .dot and .dotx files.)
The way you design the template (see the Axiell Collections Help) determines if every record is printed on a separate page or not, and which tags and how many occurrences will be printed. A label template (also supported by Axiell Collections) requires a special design.
Obsolete output formats based on a .dot or .dotx template simply won't show up in Axiell Collections and will only be visible in Adlib for Windows. If an output format is set to a .dot or .dotx template, while a .docx template with the same name is present in the same folder too, then Axiell Collections will show the .docx template as one of the available output formats instead.

For Axiell Collections (as well as for Adlib), translations of templates are supported. Like text and help files, Word templates which are available as output formats in your application, are interface language dependent. For the user, interface language dependence means that a selected template will usually contain texts and labels in the current interface language of the application. For example, if you display the menu’s in Dutch, then you’ll automatically be working with Dutch templates (if available). For the maker of templates, interface language dependence means that you have to create a separate template for each language in which users may want to work. So, of the same template there may exist different translations, each in its own file, for every interface language that you wish to make available to users of your application. For example, if your application is being used by Dutch and English speaking users, then you should have at least a Dutch template and an English template for each print task.
The software recognizes the language of a template file by the number at the end of the file name: 0 = English, 1 = Dutch, 2 = French, 3 = German, 4 = Arabic, 5 = Italian, 6 = Greek, 7 = Portuguese, 8 = Russian, 9 = Swedish, 10 = Hebrew, 11 = Danish, 12 = Norwegian, 13 = Finnish and 14 = Chinese. So a new template for printing an accessions list, with English texts on it, should be named e.g. accessionslist0.docx. The same template, translated to Dutch, then becomes accessionslist1.docx. (Note that you must keep the name of the file the same, aside from the language number, meaning: untranslated.) The template name to specify here in the Template path option, is always the name without any language number, so accessionslist.docx for example.

When the user selects a Word template to print to, the software will try to load it as follows:

You can use an adapl to pre-process data, if you wish, before the template is processed. Such an adapl can be set in the property above.

Template type

The Template type indicates the type of template (if you use one):

Print service

In combination with a Raw template type XSLT stylesheet (to be specified in the Template path option above) which outputs raw ZPL (for Zebra printers) or IPL (for Intermec printers) control codes, a Windows print service (as an IIS application) can be used for directly printing labels from within Axiell Collections.

Parameters screen

To be used in a prompted output format setup. Refer to a screen file (.fmt) with entry fields if you want to offer the user the possibility to enter some details which must be printed too or used some other way by the output format. All fields (parameters) placed on the screen must also have been defined underneath the current output format definition.

Stylesheet XML type

If you are using an XSLT stylesheet as an output format (in which case the stylesheet(s) have been specified in the option below), you must indicate here which XML type is expected by the stylesheet(s): Grouped or Unstructured. Any XSLT stylesheet output formats created prior to Adlib 7.1 will always be based on unstructured XML. From Adlib 7.1, the new XML type option will also default to Unstructured for existing output formats; in new output formats though, it will default to Grouped. Only from Adlib 7.1, you can choose whether to base your stylesheet on grouped or unstructured XML. Click here for more information about the differences between the two formats.

Stylesheet Path

This option allows you to set one or more XSLT stylesheets to be used as an output format. XSLT stylesheets are UTF-8 encoded text files with the extension .xsl or .xslt. XSLT 3.0 and earlier versions are supported from Collections 1.14: only XSLT 1.0 was supported before that.
All entered stylesheets for an output format are executed in sequence, from top to bottom, when printing. This allows you to spread complicated transformations over different stylesheets.

Job title

Enter a name for this output format in one or as many languages as you wish to make available to users. These names will be used in the Output formats dialog.

Job description

To elucidate this output format you may provide short descriptions. These will not be visible to the user.

Requested fields

Optionally to be used for the Raw Template type, for which you do not need the entire record but just a small selection of fields. To enhance performance during output you can list the desired fields here. If you do not specify Requested fields, the whole record will be available to the stylesheet (and the optional preprocess adapl).