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