[PAGES-1167] Incorrect placement of green bars with Web Components Created: 17/May/23  Updated: 13/Dec/23

Status: Accepted
Project: Magnolia pages module
Component/s: None
Affects Version/s: 6.2
Fix Version/s: None

Type: New Feature Priority: Neutral
Reporter: Fabian Illsinger Assignee: Robert Šiška
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: PNG File Screenshot 2023-07-26 at 15.36.26.png     PNG File Scrreenshot of editor view.png     Zip Archive Simple Webcomponent Example.zip     Zip Archive grid-example.zip    
Issue Links:
relation
Template:
Acceptance criteria:
Empty
Date of First Response:
Epic Link: Support
Team: DeveloperX

 Description   

Status: For PD Developer: [See call notes|https://wiki.magnolia-cms.com/display/DEVINT/Web+Components+in+Page+Editor+-+Prodyna]

Dear Magnolia Team,

as we discussed in our meeting on the 9th of May with Jürgen Brömmer, Richard Gange and Christopher Zimmermann,
we provide a minimal example (Simple Webcomponent Example.zip) of our problem as well as some ideas for a solution from our side.
We also describe our problem in more detail.

Introduction to the problem:

In our freemarker files we are using webcomponents with named and unnamed slots as definined by the webcomponent standard.
The Mozilla documentation gives a good overview over webcomponents.
Here you also find a comprehensive guide with some example.

All our freemarker files only consists of one single webcomponent. e.g.

# example freemarker file
<ui-cms-text-image-video body='{Custom JSON with Dialog values}'>
</ui-cms-text-image-video>

We provide all information of the dialogs to the webcomponent. The webcomponent is then responsible for building the visual html elements that the user or editor can see.

As you can see in the image "Screenshot of editor view" in some webcomponent usage scenarios the editor bar of a component is placed at the wrong place.

Detailed description of the problem:

In our example we provide three magnolia components.

  • wrapper-componet
    • this component simply holds an area so that you can place the two other components in it.
  • test-text
    • this component simply shows some text
  • test-text-with-slot
    • this component uses the same webcomponent as the one above but also provides a slot name

We now take a closer look at wrapper component.

# wrapper-component.ftl
<wrapper-component>
    [@cms.area name="myTestArea"/]
</wrapper-component>

The underlying template of the wrapper-component webcomponent looks as follows:

<div style="background-color:#1589FF;">
    <slot name="mySlotName"></slot>
    <div style="height: 50px;"></div>
    <div style="padding-top: 150px;">
        <slot></slot>
    </div>
</div>

1) When you place the test-text (Text Component) component in the wrapper-component, the editor bar for the test-text component is placed correctly. The area top editor bars not.

This can be explained, due to the fact that we use an unnamed slot <slot></slot> that will receive all html elements without slot name that are placed within the [wrapper-component] tags.
This means that also the editor bars div tags will be placed into this slot alongside the test-text webcomponent. The order of the html elements stays the same.

2) When you place the test-text-with-slot-name (Text Component (Named Slot)), the editor bar for the test-text component is placed below the component. The top area bars are still placed inside the blue container and not above it.

You see the text on the very top of the container, whereas the editor bars are on the very bottom. This can be explained, because the editor bars are placed in the unnamed slot, which ist the last element in the template.
On the other side, the test-text component with slot name will be placed in the first element <slot name="mySlotName"></slot> in the webcomponent template.
Hence the editor bar for the component and the area are underneath the text component.

So we have one problem for the component and one problem for the area.

Ideas for a solution

We see two steps that are necessary for a fully functional solution:

Individual slotting of editor bars

The solution we see here is, that magnolia could provide slot names on the mgnlEditor Bars for the area mgnlEditorBarStart and mgnlEditorBarEnd and component mgnlEdtorBar.

The rendered editor bar would look like this for example:

<div slot="mgnlEditorBarStart" class="mgnlEditorBar mgnlEditor area start mgnlEditorBarStatusIndicator focus" style="">...</div>

This means a developer of a webcomponent could choose for himself were to place the editor bars. The following example demonstrates the webcomponent template:

<div style="background-color:#1589FF; padding-top: 149px;">
    <slot name="mgnlEditorBarStart"></slot>
    <slot name="mySlotName"></slot>
    <div style="height: 200px"></div>
    <slot></slot>
    <slot name="mgnlEditorBarEnd"></slot>
</div>

In the magnolia component/area definition you could turn on/turn off this feature by using e.g. useEditorBarSlots: true.
Allowing this setting is necessary, because if a developer only uses an unnamed slot, all elements for a named slot will not be displayed.
The default behaviour would be that magnolia does not provide a slot name. Only if the developer uses the proposed setting, the slot name will be placed on the div for the editor bar.

Placing all editor bars inside the webcomponent

We think that the first proposed solution should already work fine, but we are not a 100 % sure. So in case the first solution does not work properly you should consider to place all editor bars inside the webcomponent.

For area bars this is working already, so the follwoing text applies for components.

It must be possible to register other html Tags other than div so that the edior bars will be placed inside the webcomponents.
From analyzing the magnolia code we saw that the following method is responsible for placing the editor bar either within the html element or before it. (see info.magnolia.ui.vaadin.external.gwt.client.editor.dom.processor.AbstractMgnlElementProcessor#attach). The logic of this code only looks for a div element.
We could imagine that it could be possible to register new html elements or prefixes of html elements, so that we can also place the editor bars within our webcomponents.
Since the code responsible for inserting the editor bars is using the java to javascript GWT generator, it could be possible to add element names to a global javascript array.

So an easy way would be that a developer could manually register a unique webcomponent name wihtin a global javascript array.
A more advanded way could be that the developer can define that unique webcomponent name in the component/area definition (e.g. tagName)

We hope that this clarifies our problem and gives you a good example.
If you have further questions, please do not hesitate to ask us.

Regards
Ferdinand, Fabian



 Comments   
Comment by Christopher Zimmermann [ 26/May/23 ]

Ferdinand, Fabian - thanks for the detailed expllanation and example. We'll take a look at it.

Comment by Christopher Zimmermann [ 01/Sep/23 ]

Hi fillsinger , Ferdinand recently wrote in email: 

  1. When testing the solution as an alternative to Bartosz’s workaround, we found that the start and end bars were not yet receiving the slot name. It worked for the component editor bar itself, which was therefore slotted properly next to our webcomponent. But as the start and end bars do not have the named slot, they are not displayed. This then also leads to the component bar not showing as it gets a display: none property from Magnolia due to the missing context from the start bar.{}{}
  2. This approach is not compatible with our current grid component due to the dynamic reslotting I mentioned in my last mail. It takes several grid element components and slots them in slots provided based on the number of components. Hence, we would need to give the same component different slot names depending on how many there are and their order which is not possible with the configuration in the component.

I just checked in with rsiska about number 1 above - and he mentioned that "Start and end bars do have the named slot if it's configured on either component or area template def."
Maybe there is somethjing specific about your project that is causing the above not to work? Could you share an example project/page where you get the incorrect behaviour? (Or is it not working for you on that project that you shared?)

Comment by Christopher Zimmermann [ 06/Sep/23 ]

Flag added

Waiting for demo project from Partner.

Comment by Fabian Illsinger [ 07/Sep/23 ]

Hello  czimmermann 

 

Maybe there is somethjing specific about your project that is causing the above not to work

 

as we mentioned in our meeting on the 4th of September we probably had some technical issues with the provided JARS. Since we decided not to pursue this approach for now, we will stop investigating were the problem resides.

Comment by Ferdinand Badenberg [ 07/Sep/23 ]

Please find attached (grid-example.zip) two very basic Magnolia components using our Frontend Grid Webcomponent, the ui-cms-grid with its ui-cms-grid-elements.

 

By integrating the grid example and adding grid element examples to its area, it can be easily seen that the editor bars are not working properly: all magnolia bars for the area as well as the grid element components are placed below the grid elements.

 

Furthermore, inspecting the dom reveals the slots generated by the Frontend: each of these full-width elements is placed in its own slot in the order they are passed in to the Frontend, labeled 0, 1, 2,...

 

This means that an interface with a slot name on a component level is not possible, as the grid elements will receive different slot names.

Furthermore, wrapping the elements with divs will break the Frontend logic looking for grid elements.

 

If the editor bars for the component were to be placed inside the webcomponent <ui-cms-grid-element>, the component editor bars would be properly slotted already, so you should be able to use this example to verify a potential solution for our use case, but also to get a glimpse into a more complex use-case of slots, where there is no clear interface for the slot names between the Backend and the Frontend.

 

If any issues integrating this example or further questions arise, please do not hesitate to contact us via Ticket/Mail.

Comment by Robert Šiška [ 30/Oct/23 ]

Current solution implements new containerElements attribute in the template definition. It is a list of HTML element names for which the greenbars will be inserted into, not above the component. It is configured in the page definition and it applies for the whole page. E.g.:

 

renderType: freemarker
templateScript: /union-investment/templates/pages/main.ftl
containerElements:
  - ui-cms-grid-element
  - other-element

The solution is on feature/PAGES-1167 branches of PLATFORM/main and MODULES/pages

Comment by Ferdinand Badenberg [ 27/Nov/23 ]

Hi all,

sorry for the unexpectedly long delay. 

I was able to test the implementation in the context of our project and am happy to report that it works as expected and solves many issues with the editor bars for us! Thank you for your work.

I only noticed two issues where the editor bars are not yet as expected. One issue we can fix on our end by refactoring the component to use the solution you provided.

The second issue and as far as I know only remaining issue is that we are unable to specifically slot the start and end bar of an area, which leads to the start bar not being at the actual start of the component area when we slot something specific above the generic slot.
However, this only occurs in two places total and in my opinion is both a very specific use case and not as big of a problem as the previous ones were. Therefore, I will check with our stakeholders if anyone there is still a need on their end on pursuing a fix for this last case.
I will get back to you in either case.

Do you have a rough estimation of the Magnolia Release/Version this fix would be deployed in for me to pass on?

Kind regards and thank you again,
Ferdinand

Comment by Christopher Zimmermann [ 01/Dec/23 ]

fbadenberg thanks for the update. Great to hear that it is working. I don't have a version/date when it will be released. As we need to look into how it fits into the current priority landscape and have some personel on break as well. 

Thanks for your further checks and updates.

Generated at Mon Feb 12 06:25:43 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.