Rob asked to move the style handling in separated task, some for you some for me.
I have done some style depending changes with this issue and worked several days on the design of this issue.
Could you give me an early feed-back and help me on the tests and if you are able on the implementation?
I would continue on the implementation tomorrow, pinging you in IRC.
I believe the design is quite stable now.
Still some of the implementation are missing and therefore tests are failing. BTW I fixed an issue in the XPath/Slide test making the problem visible, making it fail.
OdfNamespaceContext was removed.
The OdfFileDom is now implementing the interface NamespaceContext, embracing the get methods from the XPath required interface and in addition set methods:
public void setNamespace(String prefix, String uri)
public void setNamespace(NamespaceName name)
to add new namespaces during SAX parsing and DOM node creation.
The specific ODF subclasses of
OdfContentDom, OdfStylesDom, OdfMetaDom and OdfSettingsDom
and the later following
will initialize the Namespace mapping map with its ODF namespaces taken from enums generated by source code generation.
(During this redesign the namespace enum ..dom.OdfNamespaceNames has been renamed to ..dom.OdfDocumentNamespace, making it easy to distinguish to the upcoming pkg.manifest.OdfPackageNamespace - see issue 71, e.g. OdfDocumentNamespace.OFFICE)
These mapping are made persistent as XML during the save of a OdfFileDom within the OdfPackage. The mapping will be saved as namespace attributes to the root element.
Note: The OdfFileDom subclasses are now the entry point for each DOM tree, e.g. for OdfContentDom
public OfficeDocumentContentElement getRootElement()
Following additional changes/suggestions:
org.odftoolkit.odfdom.pkg.OdfXMLHelper.java was only used by tests and moved to test package, as the class is more a tool based on ODFDOM than a required part of ODFDOM.
2) Not used/required and removed for simplification:
has to be moved to the pkg Java package.
The reason: All DOM need to be saved when the package is saved (precondition of 219). To archive this the class
have to be on the same level as OdfPackage to be able to add itself during construction (constructor) to the collection of DOM the OdfPackage will hold.
Exact the same principle as the OdfPackageDocument adds itself to the Package (updated the issue 219).
After the move of this class, I believe only the JarManifest class remains in org.odftoolkit.odfdom.
all other classes should similar moved to pkg Java package. For example OdfExample would describe XML elements within the package.
Not certain yet if alien attribute/element classes should remain. (NOTE: This multiple class move should be done after first review to minimize the changes in files. You might even want to change the package of OdfFileDom back before review to avoid so many tiny changes.)
What is missing...
I) A test document where other namespace prefixes were used than usual in ODF.
II) A test document where within a document the similar prefix is defined to a different URI
I would suggest to continue on OdfFileDom:
1) The setNamespace() method needs to be called by SAX Parsing and all DOM creation adding a new namespace.
2) In addition we might do some collision detection, when a new prefix/URI pair is being added and
a) the URI was already used:
Use the existing prefix, neglect the given
b) the prefix was already used:
Change the prefix in a symetric manner, e.g. append "_1".
If the changed prefix was already used and NOT the same URI, incrementing the number to "_2" and loop this.
We would document this and users have to take care for their attribute values using namespace prefixes.
I neglected the thought on parsing all attribute values for ':' or the feature of allowing the change of a namespace prefix.
3) OdfFileDom needs a package level access method to provide the map (the one where the URI is the key - as only doubled prefixes might cause trouble).
4) OdfContent, etc. would loop over the enum, ie. for(NamespaceName name : OdfDocumentNamespace.values()) and fill the map.
After this issue, I would ask you to devide the doc.OdfDocument (and subclasses) into dom.OdfDocument (and subclasses).
(I have created ODFTOOLKIT-158 - "Separation of DOM dependencies of doc.OdfDocument to dom.OdfDocument")
Only the DOM documents should be aware of XML details as content.xml, etc.
From pkg.OdfFileDom the following methods have to be moved to dom.OdfDocument (or removed):
public OdfOfficeAutomaticStyles getOrCreateAutomaticStyles()
public OdfOfficeAutomaticStyles getAutomaticStyles()
public OdfOfficeStyles getOfficeStyles()
We have to move those, as no user would like to care if he has the automatic styles of the content.xml or the styles.xml, he would only access these information at the OdfDocument. In addition the pkg layer is not allowed to access classes from the upper ODF XML layer.
An interesting question will become obvious (again) how DOM to DOC documents access each other? Both are the entry points for the DOM and DOC API. Most likely by composition having references to each other (or creating them on demand), while DOM is created during loading anyway.