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
model
like${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.