What happened. Two views embedded the Vaadin markdown component declaratively:
<markdown id="previewMarkdown" width="100%"/>
compileJava is clean — it never reads descriptors. clean test was green: the
context-load tests boot the application but do not OPEN any view. The mechanical
descriptor checks in jmix-ide-static-analysis do not cover this either — there is no
msg://, no property path, no data container involved. The defect appeared only when a
browser actually opened the view:
GuiDevelopmentException: Content cannot be null or empty
Frame ID: Document.prepare
MarkdownLoader requires a non-empty content attribute (or nested <content> element)
and throws at load time when both are absent. Two views were affected; both would have
reached production broken.
What fixes it. A placeholder string set from the message bundle:
<markdown id="previewMarkdown" width="100%" content="msg://preview.empty"/>
Why it matters for the skills. jmix-create-detail-view lists two "render-time killers
that compile clean" (enum bound to entityComboBox, itemsQuery without a nested
<query>). This is a third one of exactly the same shape, and the component is the obvious
choice for any view that shows markdown — which an agent-authored document system will
reach for immediately. One line in that list would prevent it.
Second-order point, worth stating in jmix-verify-bootrun: the cheap, permanent guard for
this defect class is a @UiTest that NAVIGATES to each new view. It costs a few lines,
runs in the normal suite, and catches every "view fails at open" defect — including the
ones no mechanical check can express. Verify the guard by removing the fix and watching the
test fail; a test that passes both ways proves nothing.
Found while building a real Jmix 2.8 application (document registry, Vaadin UI, PostgreSQL, deployed behind nginx).
What happened. Two views embedded the Vaadin markdown component declaratively:
compileJavais clean — it never reads descriptors.clean testwas green: thecontext-load tests boot the application but do not OPEN any view. The mechanical
descriptor checks in
jmix-ide-static-analysisdo not cover this either — there is nomsg://, no property path, no data container involved. The defect appeared only when abrowser actually opened the view:
MarkdownLoaderrequires a non-emptycontentattribute (or nested<content>element)and throws at load time when both are absent. Two views were affected; both would have
reached production broken.
What fixes it. A placeholder string set from the message bundle:
Why it matters for the skills.
jmix-create-detail-viewlists two "render-time killersthat compile clean" (enum bound to
entityComboBox,itemsQuerywithout a nested<query>). This is a third one of exactly the same shape, and the component is the obviouschoice for any view that shows markdown — which an agent-authored document system will
reach for immediately. One line in that list would prevent it.
Second-order point, worth stating in
jmix-verify-bootrun: the cheap, permanent guard forthis defect class is a
@UiTestthat NAVIGATES to each new view. It costs a few lines,runs in the normal suite, and catches every "view fails at open" defect — including the
ones no mechanical check can express. Verify the guard by removing the fix and watching the
test fail; a test that passes both ways proves nothing.
Found while building a real Jmix 2.8 application (document registry, Vaadin UI, PostgreSQL, deployed behind nginx).