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