Details

    • Type: Task
    • Status: Closed
    • Priority: Neutral
    • Resolution: Fixed
    • Affects Version/s: 2.1.8
    • Fix Version/s: 2.2
    • Labels:
    • Release notes required:
      Yes
    • Documentation update required:
      Yes
    • Sprint:
      Basel 111, Basel 112, Basel 113, Basel 114, Basel 115, Basel 116
    • Story Points:
      21
    • Magnolia Release:
      5.6

      Description

      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.

        Attachments

          Activity

            People

            • Assignee:
              pmundt Philip Mundt
              Reporter:
              mmuehlebach Michael Mühlebach
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: