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]

Reply via email to