[MGNLCTS-92] Remove uses of the Content API Created: 14/Jul/17 Updated: 02/Oct/17 Resolved: 28/Sep/17 |
|
| Status: | Closed |
| Project: | Content Translation Support |
| Component/s: | None |
| Affects Version/s: | 2.1.8 |
| Fix Version/s: | 2.2 |
| Type: | Task | Priority: | Neutral |
| Reporter: | Michael Mühlebach | Assignee: | Philip Mundt |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | tech-debt | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||
| Template: |
|
||||
| Acceptance criteria: |
Empty
|
||||
| Task DoR: |
Empty
|
||||
| Release notes required: |
Yes
|
||||
| Documentation update required: |
Yes
|
||||
| Epic Link: | Remove Content API | ||||
| Sprint: | Basel 111, Basel 112, Basel 113, Basel 114, Basel 115, Basel 116 | ||||
| Story Points: | 21 | ||||
| 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 artifactsThe new modules are:
The old artifact
Overview of changesPropertiesToTranslateFinder (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.commandsAll 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.definitionTranslationFileFormatOptionGroupFieldDefinition 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. |