Introduce component library (document, page, pane, image, text, table)

[voytech]

A drastic change. Documents should be top level API that can include 'Aggregate Root' model sub apis ( sub projects, sub models, sub operations , sub states)

Document API should be different module - or even different project that holds general contracts. Responsibilities should be:

• RenderingContext management
• installing stand alone 'aggregate roots' - like entire 'Tabulate' project.
• providing RootOperationTemplate implementations (currently TabulationTemplate)

Api should provide currently minimum set of components:

• document
• sheet
• page
• table (Further is should be easy to add support for new components like lists, grids, panes, title bars, areas.

When above feature will be available, tabulate eventually becomes document DSL library.

Sub-tasks:

• [x] Add component model infrastructure,
• [x] Add layouting support
• [x] Add export suspension/resuming (for paging)
• [x] AttributedContext -> Renderable + bbox as property
• [x] LayoutQueries -> LayoutPolicy
• [ ] RenderOperation returns Result with potentially refined bbox to apply on layout + Status (OverflowStatus)
• [x] ExportTemplate adds method 'computeSize' that performs only dry run.
• [x] Generalize ExportOperationProvider ad OperationProvider with subtypes: ExportOperationProvider + MeasureOperationProvider
• [ ] Make each TemplateContext consisting of Scope and State. Where scope exposes API for Template and hides internal ExportInstance API. States - contains all data related to template export progress.
• [ ] Add better discrimination between 'Size bounded' rendering contexts and unbounded ones.(excel, cli,csv are unbounded. PDF is bounded cose contains page)
• [x] LayouyPolicy implementations should enhance Layout with more glanural layouting queries... eg should GridLayoutPolicy should be able to provide requested column width. When a width is queried it may return null e.g when Layout is not concluded. Concluded layout is a layout that has been exhausted by associated ExportTemplate.
• [x] Introduce MeasuringLayout or MeasuringGrid which has only size without position. MeasuringGrid is used by MeasureOperations to keep component size, and flag if measurement is concluded. When starting export after measurement, active regular layout should set maxRightBottom from MeasuringGrid size. Also LayoutPolicy relative renderable context measures should bind to regular Layout for export to provide valid measures for bboxes.

[voytech]

TemplateContext should not have generic type for RenderingContext. RenderingContext is export scope property and can be moved to export parameter list. This will allow to drop casts on TemplateContext.

[voytech]

Attribute merging strategy:

1. AggregateModel should be replaced with Model. Model maintains AttributeGroups (attributes with categories they belong ) and defines set of ownedAttributeCategories ( attributes that are recognized by its ExportTemplate)
2. When building TemplateContext a template must discover all downstream Models and collect its ownedAttributeCategories to compute all categories of attributes that must be merged from parent AggregateModel (AggregateModel is now model that have child Models). Above requires a generic methods on AggregateModel to access its AttributesGroups as well as to access childModels.
3. Logic for merging and passing attribute groups should be done whe TemplateContext is created.
4. Only AggregateModel have childModels and ownedAttributeGroups, Model has only ownedAttributeGroups.

[voytech]

Layouting.

1. Layouting state should be associated with RenderingContext, as different context uses different units for coordinate system.
2. Layout engine should be generic but operate on RenderingContext specific coordinate system.
3. Layouts should not be controlled by client code, instead each operation dispatched from ExportTemplate should be first wrapped by something like LayoutProxy or LayoutInterceptor to recieve layout directives from rendered context models and attributes.
4. LayoutProxy, after receiving layout directives from rendered context models and attributes, should alter global layout parameters. Global layout parameters needs to be present on RenderingContext.
5. Units conversion must be possible as long as attributes may have defined different units.
6. What about auto size offered by third party rendering libraries - is a feedback from renderer required ? What about default column widths e.g.? Should be read by rendering context ... should I perform default metrics detection from underlying engine?
7. Should be possible to define default metrics : default row height, default column width,

[voytech]

Drop loading of ExportTemples using ServiceLoader. It is not required complexity. It is enough that each model declares method:

getExportTemplate

ServiceLoder should be used only for DocumentFormat related infrastructure as this is only pluggable.

As long as we have model we should already know how to export it by its type.