Remove uses of the Content API

This issue relates to the epic "Remove Content API". See https://wiki.magnolia-cms.com/pages/viewpage.action?pageId=136852051 for further detail.

During the various sprints this ticket was in, we figured the best approach to getting rid of the content API was to create a new translation module. We would take the change and cleanup the API and problematic code (a lot) along the way.

New artifacts

The new modules are:

• info.magnolia.translation:magnolia-content-translation:2.2-SNAPSHOT and
• info.magnolia.translation:magnolia-content-translation-pages-integration-app:2.2-SNAPSHOT split out integration into pages app – used to be in the module itself).

The old artifact

• info.magnolia:magnolia-module-content-translation-support:2.2-SNAPSHOT is now being redirected to
• info.magnolia.translation:magnolia-content-translation-support-compatibility:2.2-SNAPSHOT.

Overview of changes

PropertiesToTranslateFinder (info.magnolia.translation.finder)

Same as before but the main difference is the underlying object. Previously called info.magnolia.module.contenttranslationsupport.export.NodeDataBundle (and also bound to Content API) the new object is info.magnolia.translation.finder.PropertyToTranslate. STK-related classes were not migrated.

Export (info.magnolia.translation.io.writer)

Previously one had to specify info.magnolia.module.contenttranslationsupport.export.AbstractTranslationBundleWriter (s) in the CTS module config. This was highly problematic because this setup was mixing config (the actual exporter config) with logic (the writer instance).

Now one specifies a info.magnolia.translation.TranslationExportOperationDefinition allowing to set a propery called writerImplementationClass which needs to be a subclass of info.magnolia.translation.io.writer.AbstractTranslationItemWriter. Per executed export operation, a new instance of such a writer will be instantiated. Note that the previous info.magnolia.module.contenttranslationsupport.export.AbstractTranslationBundleWriter#init(java.io.OutputStream, java.util.Locale[], java.util.Locale) methods were removed in favor of constructor parameters eleminating the need to call the init method before anything else.

Import (info.magnolia.translation.io.reader)

So above section about export. Similarly there is a new definition called info.magnolia.translation.TranslationImportOperationDefinition that allows to specify an op incl. a readerImplementationClass property. This class needs to extend info.magnolia.translation.io.reader.AbstractTranslationItemReader. Same cleanup effort was done as with the writers.

Export / import execution (info.magnolia.translation.io)

The legacy module contained to separate beans for imports (info.magnolia.module.contenttranslationsupport.reimport.TranslationBundleUpdate) and exports (info.magnolia.module.contenttranslationsupport.export.TranslationBundle). One was produced to write to files, the other to read from files. There is now one single bean info.magnolia.translation.io.TranslationItem (incl. a builder) for both scenarios.

One indirection for the export via info.magnolia.module.contenttranslationsupport.export.TranslationBundleExporter was completely removed and the info.magnolia.translation.io.ContentTransporter was cleaned up. It now takes a TranslationExportOperationDefinition for exporting data and a TranslationImportOperationDefinition when importing data.

Export still mainly happens in info.magnolia.translation.io.ExportVisitor and the import in info.magnolia.translation.io.TranslationItemImporter.

All code involved was clean up and logic was moved to where is was appropriate.

Commands info.magnolia.translation.commands

All deprecated commands were removed and both info.magnolia.translation.commands.TranslationFileUploadCommand and info.magnolia.translation.commands.TranslationFileDownloadCommand now extend info.magnolia.commands.MgnlCommand. Default configured commands come in catalog translation.

Actions (info.magnolia.translation.ui.action)

Previously, OpenCreateTranslationFileUploadDialogAction was bound to store any uploaded file in the website repository. This was changed: the action now uploads any binary into the workspace of the underlying item. Additionally the action used allow multi-items even though it was not extending the appropriate super class (hint AbstractMultiItemAction). This was cleaned up.

TranslationFileDownloadDialogAction duplicated a ton of code from the AbstractCommandAction. Now it properly inherits from this action and only "overrides" logic by utilizing either #onPreExecute() or #onPostExecute(). Same goes for TranslationFileUploadDialogAction.

Field info.magnolia.translation.ui.form.field.definition

TranslationFileFormatOptionGroupFieldDefinition used to contain logic to read from the module config to show a list of available formats (next to a pretty broken definition itself). This was wrong. Now we use a custom factory (TranslationFileFormatOptionGroupFieldFactory) that reads a simple config and produces the desired field. An updated fieldType definition was added.