High level workflow
Template registration
The concept of telling your web portal, that a certain document is to be used as a template. You enter the document ID into the list of possible templates
Template overview
Typical usecase could be to have an e-commerce shop, where you see the possible elements you can order. In a web-to-print webshop, this element can be customized. So, you’ll need a template, to enable the end-user to customize certain elements.
Pre-processing
This optional step would be to pre-populate information into the template, before the user gets access.
Imagine a CRM database, where the information of the logged-in user can be pre populated, before the user can interact with the document. No need to enter you phone number for a business card, if the system allready knows this.
Editing
The step where the end-user can interact with the document. How the interaction happens, is defined by the template administrator. How much freedom do you give the end-user, what tools are available. This is defined in the Workspace.
Post-processing
This step in the process, optional, could allow your system to e.g. combine different elements into 1 set, before the output happens.
Output
Output is requested to the CHILI publisher engine. This output could be PDF, Images, ODF, XML, HTML, …
Inital training
While we do recommend some training for complex projects, a standard integration in a web2print portal (especially when embedding CHILI into a pre-existing portal) usually doesn't require formalized training. The basic steps for integrating CHILI (referencing documents, extracting thumbnails, embedding the editor, generating PDF files, ...) are used by pretty much all customers, and are easy to figure out based on the documentation.
The CHILI API
CHILI Publisher comes with a rich set of API functionalities. In fact, our own interfaces (BackOffice, Editor, InDesign Extension, ...) use the same API functions available to our customers. You can find all of the documentation at CHILI API Guide
Development vs. Configuration
After initial integration of CHILI in a web portal, no additional development tends to be needed (except to enable large new sets of functionalities, of course). Many features (even new features) can be configured by administrators in the WorkSpaces and ViewPreferences for the documents. If the development team builds in a good way for the administrators to link these together (on a template or category level within the portal, for example), it's up to the administrators to make the right choices based on the document or user level