[
https://issues.apache.org/jira/browse/ODFTOOLKIT-45?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Florian Hopf updated ODFTOOLKIT-45:
-----------------------------------
Fix Version/s: (was: odfdom-0.8.7)
> Provide only allowed newChildElement methods dependent on attribute value
> -------------------------------------------------------------------------
>
> Key: ODFTOOLKIT-45
> URL: https://issues.apache.org/jira/browse/ODFTOOLKIT-45
> Project: ODF Toolkit
> Issue Type: Bug
> Components: java
> Affects Versions: simple-odfdom-0.8
> Environment: Operating System: All
> Platform: All
> Reporter: Svante Schubert
> Assignee: issues
>
> I am aware of two situations, where a different child(or descendant) element
> is allowed dependent of an attribute value of an element.
> The occasions are:
> 1) The element <style:style> has a mandatory attribute @style:family
> dependent on its value a different set of <style:*-properties> is allowed.
> 2) The root element <office:document-content> has an attribute
> @office:mimetype. Dependent of this the mandatory <office:body> has a
> different child element.
> Design draft:
> Regarding 1):
> Currently it is possible to create a <style:style> element without setting
> the @style:family in the constructor, we should consider to change this.
> Imagine we would like to solve this problem using class inheritance, having
> an abstract package viewable StyleProperties class, where all other possible
> styleProperties inherit from (we might use an interface instead of
> inheritance, to be solved during prototyping).
> If we would restrict the creation of the style:*-properties element to have
> the family attribute value provided in the constructor signature, we could
> already choose the correct subclass during creation time. The problem would
> be solved.
> Init() would be called from the constructor (or removed as it would become
> redundant).
> Regarding 2):
> As the dependent element is not a child, but a descendant element the
> solution needs a further step:
> We might think about not only creating one element in the ODFDOM DOM level,
> but as well multiple, if they are mandatory.
> For instance, if we would create an <office:document-content> element, we
> might as well automatically create the mandatory <office:body> and the
> mandatory child (for instance <office:text>).
> By doing this, it would become obvious that the constructor of
> office:document-content needs more arguments than only the fileDom and the
> init() more than the @office:version. We need the mimeType of the document,
> which is not required by attributes, but by the constraint of providing
> descendant children elements!!
> The benefit of this solution, we could generate it. All parent elements of
> office:text, office:spreadsheet, etc. have to provide the choice in the
> signature. We as developer know, that the choice does not have to be the
> attribute name, but the MIME- or mediaType.
> As inheritance is a possible way to solve this problem, I made this dependent
> of ODFTOOLKIT-44, the exchange of the DOM implementation inheritance with
> composition, as there is only single inheritance allowed in Java.
--
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
