[
https://issues.apache.org/jira/browse/ODFTOOLKIT-182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Florian Hopf updated ODFTOOLKIT-182:
------------------------------------
Fix Version/s: (was: odfdom-0.9)
> Usability: Adding optional Maps to generated ODF sources for indexed ODF
> elements
> ---------------------------------------------------------------------------------
>
> Key: ODFTOOLKIT-182
> URL: https://issues.apache.org/jira/browse/ODFTOOLKIT-182
> Project: ODF Toolkit
> Issue Type: Improvement
> Components: codegen
> Affects Versions: odfdom-0.8.7
> Environment: Operating System: All
> Platform: All
> Reporter: Svante Schubert
> Assignee: devin
> Priority: Minor
>
> Where to place the source for the access of indexed ODF components in ODFDOM?
> Giving an example:
> In ODF a master page is represented by the <style:master-page> element.
> One ore more of these master pages may be located beyond
> <office:master-styles>, the index is the their @style:name attribute.
> Similar scenarios can be found often in ODF, for instance for styles (ie.
> <style:style>) beyond <office:styles> and <office:automatic-styles>, which
> are referenced by their @style:name (in this case in conjunction with their
> @style:family).
>
> The interesting question arises, where to place the usability methods to
> access a certain style, for instance an automatic style.
> Let's start to see, where they do not belong:
> Package level (pkg Java Package):
> Automatic styles explained in part 1, the ODF XML Schema Specification and
> should therefore not be handled in the package level, explained by part 3 of
> ODF 1.2 specification.
> Convenient Level (doc Java Package):
> The existence of automatic styles is an implementation detail. The user would
> prefer to assign styles "hard" to a styleable element. Not required to know
> how in the ODF XML this is handled.
> There for the middle, the typed DOM layer remains.
> The downside those sources are being generated and the above functions have
> to be added.
> The idea arises that there is a new Java source template (for our Velocity
> template engine) that adds Map support for every element, which have in the
> Schema multiple children having an ID.
> The ID might be of type ID or as in the ODF case being added by configuration
> offering e.g. style:name.
> In addition DOM methods have to be overwritten to cover changes on those
> keyed children or the key values to keep those Maps in Sync.
> It have to be decided for each case if those map objects should be created on
> demand (on first method call - likely the default behavior) or being filled
> during loading the document (parsing the XML).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
