[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: |
|
||||
| Issue Links: |
|
||||
| Template: | |||||
| Acceptance criteria: |
Empty
|
||||
| Date of First Response: | |||||
| Epic Link: | Support | ||||
| Team: | |||||
| 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, Introduction to the problem:In our freemarker files we are using webcomponents with named and unnamed slots as definined by the webcomponent standard. 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.
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. 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. So we have one problem for the component and one problem for the area. Ideas for a solutionWe see two steps that are necessary for a fully functional solution: Individual slotting of editor barsThe 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. Placing all editor bars inside the webcomponentWe 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. So an easy way would be that a developer could manually register a unique webcomponent name wihtin a global javascript array. We hope that this clarifies our problem and gives you a good example. Regards |
| 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:
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." |
| Comment by Christopher Zimmermann [ 06/Sep/23 ] |
|
Waiting for demo project from Partner. |
| Comment by Fabian Illsinger [ 07/Sep/23 ] |
|
Hello czimmermann
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
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. 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, |
| 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. |