[MTE-124] Introduce MTK2 with M6 dialogs Created: 14/Jan/20  Updated: 21/Dec/21  Resolved: 07/Jun/21

Status: Closed
Project: Magnolia Templating Essentials
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0

Type: Task Priority: Neutral
Reporter: Christopher Zimmermann Assignee: Roman Kovařík
Resolution: Done Votes: 0
Labels: VN-Testing
Remaining Estimate: Not Specified
Time Spent: 4h 10m
Original Estimate: Not Specified

Issue Links:
Cloners
is cloned by MTE-125 Cover MTK M6 dialogs with tests Closed
Relates
relates to MTE-113 Texts on pages done with mtk:pages/ba... Closed
dependency
is depended upon by MGNLDEMO-363 Update Travel Demo dialogs and apps t... Closed
is depended upon by NPMCLI-258 Support MTK2 Closed
supersession
supersedes MTE-108 Update dialogs in MTK to use $type alias Closed
Template:
Acceptance criteria:
Empty
Task DoR:
Empty
Date of First Response:
Epic Link: Migrate MTK to new framework
Sprint: UI FW 29
Story Points: 5

 Description   

Update MTK dialogs to M6

  • Ensure that it is possible for projects which are using the existing MTK templates to still function correctly with either no or a logical and easy migration path. For example, a customer project may be extending or decorating the MTK definitions.
  • Use new $type aliases wherever possible.


 Comments   
Comment by Simon Lutz [ 27/Feb/20 ]

For now: make sure conversion/compatibility works well rather than going for the actual update. Update to happen later.

Comment by Šimon Demočko [ 04/Feb/21 ]

Hi czimmermann. We're wondering:

  • either we create MTK-M5 for compatibility and MTK for new, which will break old pages using those
  • or we keep MTK for old and name the new MTK-M6, not breaking anything, but if you'll want to use the new, you'll refer to them with this version in the name. 
    • basically same issue as having app-id as pages for old and pages-app for new.
Comment by Christopher Zimmermann [ 04/Feb/21 ]

Great question. I have removed that explicit approach from the ticket description.

Idea:

Does anything speak against just changing the definitions and creating a new major version of the MTE, (1.6 or 2.0)  - and then each project can choose which version of MTE/MTK they want to use?

But then how to handle bundling? To not introduce a breaking change in a minor version, I guess we still have to bundle MTE 1.5 series with 6.2 series and then update to new dialogs in MTE 1.6/2.0 only with Magnolia 6.3. (However, in the demo bundle we could already switch to the MTE 1.6/2.0 I would think.)

Or could we introduce the changes on the 6.2 series and just advise customers if they want to keep using MTE 1.5 for compatibility reasons they can just use that in their own custom bundle?

Comment by Roman Kovařík [ 04/Feb/21 ]

Or could we introduce the changes on the 6.2 series and just advise customers if they want to keep using MTE 1.5 for compatibility reasons they can just use that in their own custom bundle?

easier to no (no compatibility module), just an update task to migrate pages/areas/component templates.
not possible to run both pages apps on the same instance
decorations/inheritance of MTK dialogs broken
we have still UI tests running in the old pages app, right? Dropping those would also mean no testing at all (especially if we will use 2.0 in our development/demo setups). Can we afford forking the tests pipelines?

I think those are the reason we haven't do this approach with other modules and we did always created compatibility modules with the old config and keeping the old module name.

 

Update: SUGGEST-257 could help.

Comment by Roman Kovařík [ 26/May/21 ]

What would the new id be? Is it possible to do it on the module name? it seems like that would be cleaner.

Demo webapp is using mtk2 templates (e.g. mtk2:pages/basic).

  • mtk(1) templates/dialogs are marked as deprecated in YAML / usages reported in def. app.

How can we help people that would like to migrate their content to mtk-2. Can we provide an optional migration?

Example update task from demo

Generated at Mon Feb 12 07:41:44 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.