[PAGES-211] Investigate: Extract GWT page-editor for standalone inclusion Created: 11/Nov/19  Updated: 17/Dec/21  Resolved: 20/Apr/21

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

Type: Task Priority: Neutral
Reporter: Mikaël Geljić Assignee: Robert Šiška
Resolution: Done Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Relates
relates to PAGES-192 Create/save parent area node upon sav... Open
relates to PAGES-238 Load SPA from external server Closed
dependency
relation
is related to PAGES-426 Establish postMessage communication i... Closed
Template:
Acceptance criteria:
Empty
Task DoR:
Empty
Date of First Response:
Epic Link: External SPA
Sprint: HL & LD 25, HL & LD 26, HL & LD 27
Story Points: 8

 Description   

TODO:

Evaluate the extracted GWT page editor. 

  • What additional tasks woudl be required to take this approach?
  • What is the estimated effort for these tasks?

 

This proposal aims at reusing the GWT Page Editor purely from the client-side, i.e. decoupling it from the Vaadin connector and RPC communication (aka Magnolia 4.5 style).

This way the current Page Editor can be shipped and included as an NPM module.

Cross-domain interaction with the Pages app goes through postMessage to communicate first with Vaadin's client-side connector, itself relaying interaction to Magnolia server-side components.

Motivation

We foresee external SPAs will be the most common case for editing SPAs from Magnolia, either pointing to a local development server, or a production environment.

Reasoning

The proper way to move forward with cross-domain iframe communication is to leverage the postMessage mechanism.

Re-implementing the whole page-editor according to this bore too much uncertainty, mostly about the logic for green bar creation/injection and focus model.
This approach preserves these two parts, and only introduces post-message communication for server-side/Vaadin interaction, such as opening dialogs, adding/moving/deleting components, etc.

So far, without this, we have a couple approaches, all of them with certain caveats:

  1. serving SPA internally from Magnolia web-resources itself:
    • "poor man's" solution for static content (pull everything from resources servlet)
    • implies synchronization overhead/copy-pasta
    • enforces magnolia light-module structure onto the frontend project
  2. serving SPA with the SPA renderer
    • needs to provide local JS/CSS bundle(s)
    • for local development, same as #1 (copy most of the project to webresources)
  3. serving SPA with Magnolia acting as a proxy
    • unreliable and cumbersome to set up, especially when project already fetches resources from multiple domains/sub-domains, or already has CSPs in place. See DEV-1353.

Prototype Implementation

Successful PoC for the standalone page-editor part, pending implementation for communication part.
Check with Mika directly



 Comments   
Comment by Christopher Zimmermann [ 11/Nov/19 ]

Do I understand correctly that the idea is that a frontend developer could include our page-editor frontend in their SPA? And then that when the SPA runs in Magnolia pages app iframe, that it correctly triggers the dialogs and actions of Magnolia?

Comment by Christopher Zimmermann [ 23/Feb/21 ]

mgeljicHow big in KB is the extracted editor, roughly?

Comment by Mikaël Geljić [ 04/Mar/21 ]

M4.5 editor (technically close) was ~ 150KB, before any optimization

Comment by Robert Šiška [ 20/Apr/21 ]

https://wiki.magnolia-cms.com/display/TH2/2021-04-19+External+SPA+-+Robert+Findings

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