Built-in components
This section describes how to use, configure and extend the generator components.
Template repositories
Template repositories maintain how the required templates are accessed.
Configuration
To bind a repository connector, the provider class and its provider-specific properties have to be specified. You can find the latter at the provider description.
# Use filesystem folder as a template repository   
repository.template.provider=org.mycompany.templaterepo.ProviderClass
Repository connectors
Filesystem repository
Retrieves templates from a filesystem location, e.g. each template is stored as a file.
repository.template.provider=filesystem.templaterepository.provider.net.videki.documentengine.core.FileSystemTemplateRepository
repository.template.provider.basedir=templates
Configuration:
| Property | Value | 
|---|---|
| repository.template.provider.basedir | Root folder location. Can be an absolute, or a relative path to app startup location. | 
Document structure repositories
Document structure repositories maintain how the document set descriptors are accessed. For handling document structures two providers are required:
- a repository for retrieving the structure descriptors (filesystem, git, postgres, mongodb, etc.)
 - a builder for parsing the descriptors (yaml, etc.)
 
Configuration
To bind a repository connector, the provider class and its provider-specific properties have to be specified. You can find the latter at the provider description.
# Use filesystem folder as a template repository   
repository.documentstructure.provider=org.mycompany.docstructurerepo.ProviderClass
Repository connectors
Filesystem doc structure repository
Retrieves templates from a filesystem location, e.g. each template is stored as a file.
repository.documentstructure.provider=filesystem.repository.documentstructure.provider.net.videki.documentengine.core.FileSystemDocumentStructureRepository
repository.documentstructure.provider.filesystem.basedir=doc-structures
Configuration:
| Property | Value | 
|---|---|
| repository.documentstructure.provider.filesystem.basedir | Root folder location. Can be an absolute, or a relative path to app startup location. | 
Document structure builders
Document structure builder control how the document set descriptors are built.
Configuration
To bind a document set builder connector, the provider class and its provider-specific properties have to be specified. You can find the latter at the provider description.
# Use filesystem folder as a template repository   
repository.documentstructure.provider=org.mycompany.structurebuilder.MyProviderClass
Builder implementations
YAML document structure builder
Parses a document structure stored in YAML format. (The source repository )
repository.documentstructure.builder=yaml.builder.documentstructure.provider.net.videki.documentengine.core.YmlDocStructureBuilder
Input processors
An input processor is a template processor, which fills in a specific template format using a given placeholder and control (for example .docx files with docx-stamper markup).
processors.provider.<input-format>=org.mycompany.docstructurerepo.ProviderClass
You can specify a list of input processors for the engine with exactly one processor per input format. The built-in configuration for example is the setup below:
processors.docx=docx.input.processor.net.videki.documentengine.core.DocxStamperInputTemplateProcessor
processors.xlsx=xlsx.input.processor.net.videki.documentengine.core.JxlsInputTemplateProcessor
Template contexts
The engine supports multiple values to be handed over to the processors. These are called template contexts. A context can either be
- global
When only one value object is used, you can simply pass it to the engine without building a context wrapper.
When using this, it will be handled as a global context, and you will have to refer the values of this object
with 
modellike${model.myValue} 
        context.addValueObject(orgUnit);
  In this case this orgUnit object can be referred as model, and its fields
with model.fieldname.
- named In case of multiple objects, you can put the DTOs into named contexts and refer them by their name:
 
        final Contract dto = ContractDataFactory.createContract();
        final OrganizationUnit orgUnit = OrgUnitDataFactory.createOrgUnit();
        final Officer officer = OfficerDataFactory.createOfficer();
        final DocumentProperties documentProperties = DocDataFactory.createDocData(transactionId);
        final TemplateContext context = new TemplateContext();
        context.getCtx().put("org", orgUnit);
        context.getCtx().put("officer", officer);
        context.getCtx().put("contract", dto);
        context.getCtx().put("doc", documentProperties);
  This way you can refer the values by their context names like ctx['contract'].field
e.q. ${ctx['contextname'].myValue}.
Implementations
Docx-stamper processor
Input format: .docx
Processes .docx templates using comment markup implemented by the docx stamper tool.
processors.provider.docx=docx.input.processor.net.videki.documentengine.core.DocxStamperInputTemplateProcessor
Noop processor
Input format: -
Simple loopback processor for returning input templates untouched.
processors.provider.noop=noop.input.processor.net.videki.documentengine.core.NoopTemplateProcessor
Jxls processor
Input format: .xlsx
.xlsx processor for processing Jxls marked-up templates.
processors.provider.xlsx=xlsx.input.processor.net.videki.documentengine.core.JxlsInputTemplateProcessor
Converters
Converters - as you may guess from the name - are format converters from an input format into an output format.
Implementations
Pdfbox docx-pdf converter
Converts docx documents into pdf using PDF box.
Result stores
Registries
Input and output types
Document structures
Document structures are a set of templates, or template alternatives (we call these TemplateElement)
with a unique id describing the content that has to be generated.
It basically describes:
- the list of template elements
 - how the result should look like: a singe, merged document is needed, or separate ones.
 - the number of copies of the whole result
 - the output format into which the result has to converted (one of the output formats or unchanged)
 
Template elements
A template element is a single template to be processed during generation identified by a given name
like "contract", etc. with locale-based alternatives and a default locale.
For example:
# contract_v02.yml
---
documentStructureId: "109a562d-8290-407d-98e1-e5e31c9808b7"
elements:
  - templateElementId:
      id: "cover"
    templateNames:
      hu_HU: "/covers/cover_v03.docx"
    defaultLocale: "hu_HU"
    count: 1
  - templateElementId:
      id: "contract"
    templateNames:
      en: "/contracts/vintage/contract_v09_en.docx"
      hu: "/contracts/vintage/contract_v09_hu.docx"
    defaultLocale: "hu_HU"
    count: 1
  - templateElementId:
      id: "terms"
    templateNames:
      hu: "/term/terms_v02.docx"
    defaultLocale: "hu_HU"
    count: 1
  - templateElementId:
      id: "conditions"
    templateNames:
      hu: "/conditions/vintage/conditions_eco_v11.xlsx"
    defaultLocale: "hu_HU"
    count: 1
resultMode: "SEPARATE_DOCUMENTS"
outputFormat: "UNCHANGED"
copies: 1
Value sets
A ValueSet is a one-time holder object, in which we collect data for a specific document structure.
The container can hold
- global value contexts
These are used for all templates not having a specific context. Use this by adding the context
with 
TemplateElementId.getGlobalTemplateElementId() - template-level contexts
If a template has to marked with a different object collection, than others, a template-level context can be added
to the value set with the required template's 
templateElementId. 
You can instantiate a value set as shown below:
    final ValueSet values = new ValueSet(structure.getDocumentStructureId(), tranId);
    values.getValues().put(TemplateElementId.getGlobalTemplateElementId(), getContractTestData(tranId));
The transaction can be bound to the surrounding business transaction.
Generation results
A generation result is another holder object containing the result document stream (when using streams without saving the result into the result store), or descriptors of the saved results.