[ 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