Closed (fixed)
Project:
Experience Builder
Component:
Page builder
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
28 May 2024 at 09:21 UTC
Updated:
28 Jun 2024 at 10:29 UTC
Jump to comment: Most recent
Comments
Comment #2
larowlanComment #4
larowlanComment #5
wim leersComment #6
wim leersDespite there now being 5 pipelines that have run, I still don't see an example of the output this generated? I feel like I'm missing something? 🙈
Comment #7
larowlanoi oi https://experience-builder-project-1508a06857f98a305db7309c5fe346249ca8....
https://git.drupalcode.org/project/experience_builder/-/pipelines/196912
Comment #8
wim leersIf we go with this, #3450308: Create an Open API spec for the current mock HTTP responses will become more important.
OTOH, if for the 0.1 milestone of we want to do a more complete demo, including Field Widget-powered editing (see #3452512: Add component instance edit form to contextual panel), it'll become less important … or to be more precise: this statically hosted demo would be a subset of the demo.
Comment #9
lauriiiI just opened #3454094: Milestone 0.1.0: Experience Builder Demo which provides some context for the question asked in #8. Given that the demo is supposed to focus on the content creation aspects of Experience Builder, it doesn't seem that it would be complete unless it includes #3452512: Add component instance edit form to contextual panel. Without that how would you change component contents?
Comment #10
wim leersMy thoughts exactly 😅
We could expand the existing mock responses to include responses for the forms, and then together with #3453690: [META] Real-time preview: supporting back-end infrastructure, that would result in live updates. I believe we need #3453690 anyway if we want to achieve the goals for #3454094, because without that, any demo will fall flat.
Comment #11
wim leers@lauriii just indicated he thinks we should NOT be doing a static demo, but an actual Drupal-powered demo.
But … this is already working and might be helpful in the short term?
I defer to @lauriii.
Comment #12
lauriiiI believe we should be keeping this as close to the real thing as possible – we want to showcase a realistic experience. My impression from what I've heard is that if we wanted to do this with mock data, we would have to re-implement lots of things from Drupal in order to provide a realistic experience on top of the mock data model. Based on that, I said that we probably should then just use a Drupal site to back the demo. This doesn't mean that we couldn't host a separate static demo in the meanwhile, we just shouldn't use it for the demo.
Comment #13
larowlanI still think this is useful for manual testing MRs without needing to check a branch out locally
Comment #14
wim leersLet's be pragmatic and get this in for the purpose that @larowlan outlines — we'll find out automatically when/where we'll hit limitations.
Per @lauriii in #12, the DrupalCon Barcelona demo (#3454094: Milestone 0.1.0: Experience Builder Demo may or may not use this, and likely won't.
P.S.: #3450308: Create an Open API spec for the current mock HTTP responses might be able to help us keep the static version of the UI useful for longer.
Comment #16
wim leers