-
Type: Sub-task
-
Status: Resolved
-
Priority: Minor
-
Resolution: Fixed
-
Affects Version/s: None
-
Component/s: Renditions
About the rendition service
Currently a rendition is a copy of a Document (or version), where the main blob has been replaced by the result of an operation.
The typical use case is transforming the main Blob to PDF.
A rendition :
- has a name
- is bound to an operation
- is stored as a placeless document
- is linked to the source document by an attribute containing IdRef
Rendition system is for now only bound to Publisher (so that we can publish a rendition).
Rendition and Template rendering
We can have a dedicated operation that using TemplateRendering to manage the rendition of a document.
Instead of a simple PDF view we can have :
- merge fields replacements in a Word / OpenOffice document
- simple page composition (Cover page, History, Formatted text)
But there are some miss-fit between the current 2 models :
- each DocumentTemplate should be seen as a potential Rendition
-> add a flag on DocumentTemplate to declare it as Rendition
-> dynamically register a rendition ?
- Template rendition can be associated with some extra parameters
(currently stored in a dedicated facet)
-> may be we should extent the rendition schema to store template related parameters ?
-> ok keep in 2 separated facets
- some renditions actually don't need to be stored for real (could be purely on the fiy)
- depends on
-
NXP-8992 Extend rendition system
- Resolved