4.0 KiB
Builds, canvas rendering and interactive previews
Build and Refresh is the activation boundary between your working project and executable preview code. Ordinary IntelliJ compilation or running Maven elsewhere does not activate a new Designer snapshot.
Snapshot lifecycle
The Designer captures the selected Maven reactor closure, copies inputs into a private build, runs the configured build and publishes immutable outputs only after success. It captures dependency identities and generated metadata together. Leases keep snapshots available while workers use them. Mutable project target directories are never the preview runtime.
Java/POM/configuration drafts must be saved through the explicit build workflow before compilation. FXML drafts can instead be supplied as private resource overlays for preview. Approval refers to exact revisions, so an edit after approval is not silently saved. Cancel stops the pending work. A failed or outdated build does not silently execute old classes: choose Preview last successful explicitly and retain its outdated indication until a successful new build.
Editable canvas
The shared Kit draws ordinary host controls and host-owned Component placeholders. A target worker loads the real parent View with a fresh sample Model graph, measures Components, and returns pixels and sizing information. The host does not construct application Components. Target minimum/preferred sizes and explicit FXML layout settings inform the projection.
Dragging/resizing remains responsive using the previous image while a newer size is rendering. Responses are accepted only for the current document revision, requested size and session. Nested and anonymous Components, repeated Components and Row source navigation use the shared workflow; individual runtime children of a Repeat are not separate source declarations. Edit their Component definition through Open Component or Open Row Component.
The canvas is a design surface, not the running application. Use interactive preview to click application controls and exercise Model write-back.
Interactive preview
Interactive preview starts a separate target JVM with its own Model/context and the current View plus known open Component drafts. It does not share the canvas Model. Restart creates fresh sample state; Stop preview closes only the owned preview. Closing its editor closes its preview while other editors remain open.
Typing later FXML drafts does not destroy interactive state immediately: the preview remains open and indicates earlier drafts. Saving an affected document restarts the preview with fresh sample state. Explicit restart also captures current drafts and clears that indication. Build changes require the normal successful-snapshot selection. Invalid bindings block new previews while leaving source editing/saving available.
An application can execute arbitrary Java in a preview. Process isolation protects host class loading; it is not an operating-system sandbox. Use deliberately harmless sample services and avoid real credentials or irreversible actions. Dispose timers, listeners and services in the sample session. Owner pipes and bounded shutdown terminate workers if the host closes or disappears; a forced kill cannot execute application cleanup guarantees.
Navigation and limits
Opening a Component selects an existing editor for the same canonical source instead of duplicating it. The parent stays open and its layout is unchanged. Standalone uses separate windows; IntelliJ uses editor tabs. Only resolvable project resources are editable; a compiled dependency's packaged resource is not an editable project source.
The current protocol bounds drafts (128 files, 1 MiB each), frame payloads and aggregate images. Resources must map unambiguously into the captured runtime. Signed JAR overlay mutation is rejected. Large applications may need smaller examples rather than unlimited payloads. The target session reference and build reference explain the implementation and validation evidence.