amondel2 commented on code in PR #439:
URL:
https://github.com/apache/grails-intellij-plugin/pull/439#discussion_r4240266988
##########
plugin/src/main/java/org/apache/grails/intellij/plugin/projectView/nodes/GrailsPsiDirectoryNode.java:
##########
@@ -104,15 +104,23 @@ protected void updateImpl(@NotNull PresentationData data)
{
}
/**
- * {@code PsiDirectoryNode.updateImpl} adds coloured fragments for module
content roots; ordinary
- * directories use {@code setPresentableText}, including qualified names
such as {@code grails-app.i18n}.
- * Gradle's per-source-set modules make {@code src/test} a content root,
whose fragments can render as
- * {@code test [app.test]}. The renderer prefers those fragments over {@code
presentableText}, so
- * setting only the latter to {@code Tests:unit} does not change that
content-root label.
+ * {@code PsiDirectoryNode.updateImpl} adds coloured fragments only when the
directory is a module
+ * content root ({@code ProjectRootsUtil.isModuleContentRoot}). Gradle's
per-source-set modules make
+ * {@code src/test} one, so it arrives carrying fragments that can render as
{@code test [app.test]}, and
+ * the renderer prefers those over {@code presentableText} — setting only
the latter to
+ * {@code Tests:unit} leaves the content-root label visible.
*
- * <p>{@code postprocess} applies the custom title to both the updated
presentation and the template.
- * Replacing any platform fragments and setting {@code presentableText}
keeps the title consistent
- * for both content roots and ordinary directories.
+ * <p>For every other directory the platform calls {@code
setPresentableText} and adds no fragments at
+ * all, so the qualified name such as {@code grails-app.i18n} comes from
+ * {@code ProjectViewDirectoryHelper.getNodeName} through that field, not
from a fragment. That is why
+ * the Views, Configuration and Initialization titles always rendered
without this hook. Do not go
+ * looking for directory-name fragments on a nested directory: there are
none.
+ *
+ * <p>Replacing any platform fragments and setting {@code presentableText}
keeps the title consistent
+ * for both content roots and ordinary directories. {@code postprocess} is a
choice rather than a
+ * requirement: the platform has already written the label by the time
either hook's body runs, because
+ * {@code super.updateImpl} is the first statement of the override, so
clearing the fragments in
+ * {@code updateImpl} would work equally well.
Review Comment:
Fixed. You were right, and the claim was wrong twice over — `updateImpl` is
not the last writer, and the existing tests could not have caught the move they
were licensing, because they call `updateImpl`/`postprocess` directly and skip
the decorators.
The paragraph is replaced: the write has to stay in `postprocess` and cannot
move into `updateImpl`, because every `ProjectViewNodeDecorator` runs between
the two hooks and `GradleModuleDirectoryDecorator` rewrites content-root
fragments — bolding the first fragment for a source-set module, and relabelling
to `"<presentableText> [moduleName]"` when the source-set name differs — so a
title written in `updateImpl` comes out restyled or suffixed. AGENTS.md says
the same thing in *Project view gotchas*.
Regression test added as suggested: `testTitleSurvivesProjectViewDecorators`
registers a decorator shaped like `GradleModuleDirectoryDecorator`'s
`appendModuleName` branch on `com.intellij.projectViewNodeDecorator` and runs
`node.update()`, asserting the drawn fragments are `["Tests:unit"]` with no
`[app.test]`. I checked it has teeth by moving the write back into `updateImpl`
— it fails there, as does `testTitleReplacesTheModuleContentRootFragments` on
its "fragments must still contain the original content-root label" assertion,
which matches what you saw at this head.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]