[MURLTRANS-3] Make property name and query node type configurable Created: 23/Apr/18  Updated: 28/Feb/22  Resolved: 27/Jul/18

Status: Closed
Project: URL Translation
Component/s: None
Affects Version/s: 5.6
Fix Version/s: None

Type: Improvement Priority: Neutral
Reporter: Richard Gange Assignee: Viet Nguyen
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0d
Time Spent: 0.5d
Original Estimate: Not Specified

Issue Links:
relation
is related to MGNLPN-396 Variant node name can be changed when... Closed
is related to MURLTRANS-2 Module doesn't work for page variants Closed
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Date of First Response:

 Description   

Due to conflicts with other modules it would be better if we allowed the URLTranslator query be configurable. This way a different property names can be used to store the translations.

Proposed configurations:

  • nodeType: the default will be mgnl:page
  • propertyName: the name of the property where the translations of page names are stored, default is 'name'


 Comments   
Comment by Richard Gange [ 23/Apr/18 ]

We also need to provide a warning in the docs that changing the node type property can slow down the query.

Comment by Viet Nguyen [ 26/Jul/18 ]

Even though using nodeType as 'nt:base' cover almost all cases but it would absolutely affect our performance a lot due to the existence of Areas, Components and customized things from clients.
Currently we only have a need to support Page variants of our Personalization, I would suggest that we'll narrow down the customizable scope to increase performance and simplify our query such as:

SELECT p1.*, p2.* FROM [mgnl:page] AS p1 INNER JOIN [mgnl:page] AS p2 ON ISCHILDNODE(p2, p1) WHERE ISCHILDNODE(p1, [/]) AND (p1.name_de = $p1 OR NAME(p1) = $p1) AND (p2.name_de = $p2 OR NAME(p2) = $p2)

Wdyt?

Comment by Viet Nguyen [ 26/Jul/18 ]

Another approach is that we'll progressively get the nodeType of nodes along current request path to 'translate' to our expected result. An example is:
/travel/kontakt/variants/variant-2
Then we'll resolve appropriate 'nodeType' along the path to do the translation, would this approach having any limitations?

Comment by Richard Gange [ 26/Jul/18 ]

I'm not quite sure what you are suggesting. For the moment we just need to query to be configurable. I would also like default values set in the code for backwards compatibility reasons.

But on the config node of the module I want to be able to set the nodeType and propertyName.

Comment by Viet Nguyen [ 26/Jul/18 ]

Finished making nodeType and propertyName configurable.

Verification steps:

1. After install the module, make sure that below nodes and properties were set:
/modules/url-translation/config@nodeType=mgnl:page
/modules/url-translation/config@propertyName=name

2. Use resources app to edit /mte/dialogs/pages/pageProperties.yaml
http://localhost:8080/magnolia/.magnolia/admincentral#app:resources:browser;/mte/dialogs/pages/pageProperties.yaml:treeview:

3. Add below code under 'form/tabs/fields':

        - name: name
          class: info.magnolia.ui.form.field.definition.TextFieldDefinition
          i18n: true
          label: Name

4. Use Pages app, edit /travel/contact page property. Set 'name' field to 'contact' in English and 'kontakt' in German.

5. Change below config to 'nt:base' to resolve mgnl:variants nodeType
/modules/url-translation/config@nodeType=nt:base

6. Open kontakt variant page using below link (change host/port and context path accordingly)
http://localhost:8080/magnolia/travel/de/kontakt/variants/variant-2.html?previewPersona=%2FStefanie-Baumann&mgnlPreviewAsVisitor=true

--> The page should be able to rendered correctly.

Comment by Richard Gange [ 27/Jul/18 ]

Looks good. I am going to merge these changes and release this today.

Comment by Richard Gange [ 27/Jul/18 ]

Fixed with v5.6.1

Generated at Mon Feb 12 11:08:39 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.