Layer independence & Google Guice

[Svante Schubert <sv...@gmail.com>]

As mentioned before, I have worked myself into Google Guice
<https://github.com/google/guice> and I am quite certain now that it is not
the correct way for the ODF Toolkit to abstract documents from the package.
Guice do not like the static factory pattern at all and even worse create
some glue code once around everything, similar as in their GettingStarted
<https://github.com/google/guice/wiki/GettingStarted>:

 public static void main(String[] args) {
    /*     * Guice.createInjector() takes your Modules, and returns a
new Injector     * instance. Most applications will call this method
exactly once, in their     * main() method.     */
    Injector injector = Guice.createInjector(new DocumentModule());

    /*     * Now that we've got the injector, we can build objects.     */
    OdfPackage OdfPackage = injector.getInstance(OdfPackage.class);
    ...
  }


Which is more boilerplate than it is now when calling
OdfPackage.loadDocument(String innerPath).
As mentioned before, the OdfPackage is using the knowledge from a higher
layer 'dom' and 'doc' Java packages to create the object for the ODF Text
or Spreadsheet document within the package on the fly.

REMEMBER: Any directory (even the root directory '/') within the zipped ODF
package is a document. Such a directory may receive a mimetype in the
package manifest and represent a 'document'.
The 'dom' and 'doc' directory refer to the directories representing
documents using content.xml, styles.xml, etc. ODF XML files.
To represent all this in Java there is a directory representation on the
pkg level 'OdfPackageDocument', inherited from this one another one on the
'dom' layer including all the references to typcial ODF XML files called
'OdfSchemaDcument' and finally on the API 'doc' level the 'OdfDocument',
which is a again child from 'OdfSchemaDocument'.
The inheritance is argueable correct as those are more specific views on
the same directory within a ZIP package.
Still I would love to try to make the XML implementation details more
invisible to the API level and drop the inheritance in exchange to a
reference and explicit return of XML details. But this is another story..

Anyway, for now as there are no other document/directory implementations
known to me atm, I will avoid the effort at the current moment to create a
dynamic factory/broker that allow 'document creator/loader' based on the
Manifest mimetype of a directory.

From my perspective, Guice would not be able to provide an elegant feature
for adding document factories for directories within the ODFPackage zip,
like reading from a config file out-of-the-box know factories and a dynamic
factory to add new mimetypes even at run-time.

Long story short, it is fine how it works now and my excurse to Guice is
finished. :)

Enjoy your week,
Svante
ᐧ

ᐧ