I apologize for reaching out at this late stage. Due to a recent medical emergency, I was unable to work on my GSOC proposal as planned. Thankfully, I'm back on track and hoping to submit my initial draft tonight if I can get some quick clarifications.
I've been very interested in the "Decoupled Editor for Plone Headless" project since it was announced in February. While I haven't been able to finalize a proposal yet, I've diligently reviewed resources to get a solid understanding of the project requirements and potential approaches.
@plone/client A rest API client to query plone6 backend.
Based on these resources, I have a few questions that I believe will help me solidify my proposal:
Q1: The GitHub issue mentions creating a new @storyblok-like package to initialize the bridge between frontend of the integrator's choice and the admin UI etc.., so we are aiming to build this package for how many frameworks like react, nuxt, next, etc. because it can help me outline my project timeline for the proposal.
Q2: The issue mentions "tracking URL changes in the iframe to update toolbars." Is this crucial for Level 1 where the layout is controlled from the Admin UI only in this level?
Q3: Final thing, as mentioned in the storyblok doc difference between decouple and headless cms here (Headless CMS Explained | Storyblok), what is our endgame, to add preview part in volto using iframe or we should be going further by enabling the inline editing too. Again asking this so I can create a solid outline for the project timeline.
I understand this is a late request, but any guidance you can offer would be greatly appreciated. I'm eager to contribute to this project and believe these clarifications will allow me to finalize a well-defined proposal for your review.
Thank you for your time and support!
Sincerely,
Mohammad Hussain,
PS: I would love to have guidance from any mentor or any of my fellow candidates who are applying for this project, and I would also appreciate any little useful insight from the mentors for this project @djay@JeffersonBledsoe
@MAX-786 thanks for the well thought out questions.
The aim is as framework agnostic as storyblok is. Storyblock you can even use when you have no frontend framework at all. I believe it should be possible to do this in a way that doesn't require different versions for different frameworks but we can discuss the options if that is not possible. But storyblok can do it so....
Volto allows you to navigate either using the contents view (editor UI) or the by clicking inside the preview page using the final sites normal navigation. In level 1 there is no bridge so no direct client side communication from the preview to the editor UI. So in order to handle the editor UI showing the right buttons and information about the current page that is in the preview page then it will use the iframe url changes to determine the current context.
However in the GSOC level 1 is the lowest priority so can be considered out of scope. This is not risky to implement so could be done last or later.
The overall goal of the PoC is to see how close we get to the full Volto editing experience but in a decoupled way.
I have been revising the PLIP and investigating and now believe that inline editing is achievable in a way that would require very little integration from the frontend developer and on any framework. Since inline editing is such a hallmark of Volto I would now prioritise this and very much like to see this as part of the GSOC if possible.
So in summary, ability to select and act on blocks, edit them inline and in the side bar live and do this in a way by including a framework agnostic js file into your frontend and some data attributes to signify your blocks and inline edit fields.
Thanks for your time and insightful answer to each question, I am glad you answered because it helped me clear my vision.
sorry sorry I looked into it last night and realized they provide these sdks to streamline integration with specific frameworks by providing pre-built functionalities, otherwise we can just use plain JS.
Thanks now I am more excited to work on thiss.
Indeed, this can be possible because after digging more into the Storyblok I got the gist that it can be possible within the GSoC timeline.
Thanks and I'll ASAP submit my first draft for this project after making the required changes.
I think a full headless solution would be two different parts.
a decoupled editing UI and restapi that has a very generic framework agnostic approach
example or starter blocks for a given framework or web components, that make the process even easier. For example a listing block in volto or the form-block has a reasonable amount of code in it outside of the editing experience. It might be attractive to a developer to not bring in a third party component but adapt one provided if they happen to be using the same framework.
2 is like a bonus. But the goal for the GSoC is make 1 happen.
Oh so its like reducing boilerplate code, so the idea is to offer these starter blocks (ex. Listing) as an option for developers using the same framework. They can choose to adapt these pre-built blocks to their specific needs instead of building everything from scratch. Did I get it correctly?
Even If this goes beyond the GSoC scope I heard the timeline can be extended so, I believe we can try achieving it later bcz this can seriously bring more attention of the developers.
This GSoC is only concerned with the decoupled editor UI. And that will be done on top of volto as it is now so that the end result is something that is fully functional.
Of course example frontends could use those components to as an example however they are React only so have limitations for use in other frameworks.
I am Ganesh Panigrahi, a pre-final year Bachelor of Computer Science student at the University of Mumbai. I'm thrilled to be applying to GSOC again this year and particularly interested in the "Decoupled editor for Plone headless" project.
While I wasn't selected for GSOC 2023 (the Nuclia Search Integration project), I learned a tremendous amount about Plone, Python, and search technologies during my application process. Though disappointed (a more experienced candidate was chosen), I'm coming back stronger and more confident in my skillset.
I'm highly motivated to contribute to the Plone community and believe the "Decoupled editor for Plone headless" project aligns perfectly with my interests. I'm eager to learn and collaborate with you all!