incubator-odf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Florian Hopf (JIRA)" <>
Subject [jira] [Updated] (ODFTOOLKIT-45) Provide only allowed newChildElement methods dependent on attribute value
Date Wed, 19 Dec 2012 06:11:19 GMT


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:
>             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:

View raw message