#1802 GUI State management implementation#1807
Conversation
- Added testing class for modals
- Added logging to IdeGuiStateManager. - Added functionality, that selecting a different project now switches the IdeContext to the new project.
- Added testing class for modals
- Added logging to IdeGuiStateManager. - Added functionality, that selecting a different project now switches the IdeContext to the new project.
…t-for-gui' into devonfw#1785-implement-modals-in-idecontext
- Added functionality, that selecting a different project now switches the IdeContext to the new project.
…plementation' into devonfw#1802-state-management-implementation
…r other ui feature branches
- added DI for IdeGuiStateManager.switchContext
Coverage Report for CI Build 26781579041Coverage decreased (-0.02%) to 71.076%Details
Uncovered ChangesNo uncovered changes found. Coverage Regressions26 previously-covered lines in 4 files lost coverage.
Coverage Stats💛 - Coveralls |
…reading the list of workspaces/projects instead of reading those from the UI
…nager, when switchContext(Path rootDirectory, ...) is called.
This reverts commit 6f92d93.
- not automatically select a workspace - to seperate concerns of which functions update the workspace combobox and which the project combobox
…low new Select-Project-Then-Select-Workspace UI logic (previous commit)
459f762 to
6c44432
Compare
…of own implementation
…plementation' into devonfw#1802-state-management-implementation
hohwille
left a comment
There was a problem hiding this comment.
@laim2003 thanks for your PR.
I like the general design and you added many valuable fixes and improvements for the GUI.
I still have some doubts about the singleton and static member access approach.
Typically this will sooner or later cause trouble.
Maybe we can avoid this where possible.
Please avoid this extensive copy&paste of pointless and confusing properties, plugin settings that are never used, etc.
The golden rule for ide-projects for test is to keep them as minimalistic as possible.
Every line from such file and every entire file that can be removed without the test failing should be removed.
regarding the singleton design, i created a new ticket to document this #1975 |
hohwille
left a comment
There was a problem hiding this comment.
@laim2003 I now found the time to read and review the entire diff.
Thanks also for your rework. This PR is very nice progress and improvement. 👍
I left some further review remarks for improvement.
We should then finally merge this instead if dying in perfection.
There will be more rounds of changes in the GUI and we should stop blocking other stories that want to build on top of this...
However, I have always learned that we always need a solid foundation rather than a sandbank to build on top. So lets keep some pair of careful looking eyes on the GUI stuff that we are evolving...
| .filter(Files::isDirectory) | ||
| .map(Path::getFileName) | ||
| .map(Path::toString) | ||
| .filter(name -> !name.startsWith("_") && Files.exists(ideRootDirectory.resolve(name).resolve("workspaces"))) |
There was a problem hiding this comment.
We should make this method reusable here:
We could even make it public if required.
BTW: The only forbidden or reserved project name is _ide and for that we have the constant IdeContext.FOLDER_UNDERSCORE_IDE.
I do not think users should do ide create _project - but I guess it is technically possible.
There was a problem hiding this comment.
Ahh yes, this was a remaining fragment from the original implementation from the first MVP. I guess, I will change this so only folders matching FOLDER_UNDERSCORE_IDE will be excuded.
| @@ -0,0 +1 @@ | |||
| this is the foo-bar workspace | |||
There was a problem hiding this comment.
Everywhere else we just use empty .gitkeep files to add a folder to git. Shouldn't we follow this pattern here as well?
There was a problem hiding this comment.
Oh ok, I will change this.
| @@ -0,0 +1 @@ | |||
| this is the foo-bar workspace | |||
There was a problem hiding this comment.
does it make sense to create project-0,..., project-5 that are all identical and have the same workspaces?
Actually if all this should make sense it would be more reasonable to have some differences between the workspaces so your test can really check if the workspaces found for some project really fit to that project and are not from a different one...
| projectManager = new ProjectManager(ideRoot); | ||
|
|
||
| assertThat(projectManager).isNotNull(); | ||
| assertThat(projectManager.getProjectNames()).containsExactlyInAnyOrder("project-0", "project-1", "project-2", "project-3", "project-4", "project-5"); |
There was a problem hiding this comment.
In cli we have added our test-infrastructure such that we can continuously add new code with new tests and potentially new test projects.
This will break as soon as we add a new test-project.
IMHO this does not really work out well for maintenance.
Maybe only assert that the project names contain these projects or filter the project names by a pattern project-[0-9] so other developers can later add foo and bar projects without breaking this test.
| void testRefreshProjects() throws IOException { | ||
|
|
||
| projectManager = new ProjectManager(ideRoot); | ||
| assertThat(projectManager.getProjectNames()).containsExactlyInAnyOrder("project-0", "project-1", "project-2", "project-3", "project-4", "project-5"); |
There was a problem hiding this comment.
Also in JUnits we can consider reuse instead of copy&paste.
Consider adding List.of("project-0", "project-1", "project-2", "project-3", "project-4", "project-5") as a constant.
Then you can create a new list adding the constant + project-6.
|
|
||
| // Verify that test-project-no-workspaces is not recognized | ||
| assertThat(projectManager.getProjectNames()).doesNotContain("test-project-no-workspaces"); | ||
| assertThat(projectManager.getProjectNames()).containsExactlyInAnyOrder("project-0", "project-1", "project-2", "project-3", "project-4", "project-5"); |
|
|
||
| // Verify that _ide folder is not in the project names | ||
| assertThat(projectManager.getProjectNames()).doesNotContain("_ide"); | ||
| assertThat(projectManager.getProjectNames()).containsExactlyInAnyOrder("project-0", "project-1", "project-2", "project-3", "project-4", "project-5"); |
| for (String projectName : projectManager.getProjectNames()) { | ||
| assertThat(projectManager.getWorkspaceNames(projectName)).containsExactlyInAnyOrder("foo-test", "main"); | ||
| } |
There was a problem hiding this comment.
This is what I was talking about. Then you could assert that project-1 has workspaces xyz and project-2 instead has abc (whatever).
And for test-data I have learned that it sooner or later hurts you if you use technical random instead of meaningful examples.
This PR fixes #1802
Implemented changes:
Main points:
Checklist for this PR
Make sure everything is checked before merging this PR. For further info please also see
our DoD.
mvn clean testlocally all tests pass and build is successful#«issue-id»: «brief summary»(e.g.#921: fixed setup.bat). If no issue ID exists, title only.In Progressand assigned to you or there is no issue (might happen for very small PRs)with
internal