Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TASK: Remove obsolete aggregate as Neos Ui handles nodeMove strategy now via special configuration #5314

Merged
merged 19 commits into from
Nov 27, 2024

Conversation

pKallert
Copy link
Contributor

@pKallert pKallert commented Oct 23, 2024

As the Neos ui now uses options.moveNodeStrategy to determine whether to move all nodes or just on dimension: neos/neos-ui#3876
And we discussed that we DONT want to make that dependant on aggregate: true in the core like in 8.3

And the fact that aggregate is now fully unused and its description and docs are outdated we removed the unused aggregate flag on NodeTypes.
It was originally introduced via defa572
We decided against using the aggregate flag to determine scatter or gather node move behaviour like in Neos 8 because the naming aggregate might be confusing now.

Review instructions

Checklist

  • Code follows the PSR-2 coding style
  • Tests have been created, run and adjusted as needed
  • The PR is created against the lowest maintained branch
  • Reviewer - PR Title is brief but complete and starts with FEATURE|TASK|BUGFIX
  • Reviewer - The first section explains the change briefly for change-logs
  • Reviewer - Breaking Changes are marked with !!! and have upgrade-instructions

Copy link
Member

@skurfuerst skurfuerst left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nice, only two nitpicks :)

@mhsdesign
Copy link
Member

Huuch i remember having created an issue for this once neos/neos-ui#3587 and funnily there was even a pr from Bernhard both for neos and the ui #4994 but that seems to be superseded then ...

@bwaidelich
Copy link
Member

In order to mimic the behavior of 9.0 we decided to introduce a setting for move strategies on NodeType level.

is that correct? I'm confused as to what this PR is supposed to solve (by just reading the description)

@pKallert
Copy link
Contributor Author

pKallert commented Nov 1, 2024

In order to mimic the behavior of 9.0 we decided to introduce a setting for move strategies on NodeType level.

is that correct? I'm confused as to what this PR is supposed to solve (by just reading the description)

Sorry, of course I meant 8.3 😄

This is for differentiating between document and content nodes when moving nodes.
For example: When moving a document node in the UI the node should be moved in all dimensions. When moving a content node (like in 8.3) the node should perhaps not be moved in all dimensions.
This is now a setting that can be set for each node type with the behavior from 8.3 set as the default.

We also talked about implementing a query window in the UI, but that could get annoying really fast especially if you move nodes very often. This can be further enhanced in future iterations but for now we landed on setting it in the node type.

There are still some edge cases that I have to have a look at and think about(when I get my local environment running again) to fix the failing test.
I updated the description accordingly and set the PR to draft since the tests are failing and my local env keeps giving errors

@pKallert pKallert changed the title FEATURE: Add nodeMove strategy configuration to nodetypes Draft: FEATURE: Add nodeMove strategy configuration to nodetypes Nov 1, 2024
@bwaidelich
Copy link
Member

Thanks a lot for the great explanation! 🤩

Comment on lines 45 to 53
{
if (str_starts_with($name, 'RelationDistributionStrategy::')) {
$name = substr($name, strpos($name, '::') + 2);
foreach (self::cases() as $status) {
if ($name === $status->name) {
return $status;
}
}
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why this complex logic, every backed enum has a built-in from and tryFrom

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In this case, we want to get the value from key.
Enum ->from gets the key from a value, as far as I understand. So I could pass gatherSpecializations and would get RelationDistributionStrategy::STRATEGY_GATHER_SPECIALIZATIONS.
Here, we have RelationDistributionStrategy::STRATEGY_SCATTER
Basically we need to cast the string RelationDistributionStrategy::STRATEGY_GATHER_ALL into an actual enum. Not sure if there is a way to do it that is not ugly?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just realized that we use a different value for name and value.
btw that's IMO a limitation of PHP enums, it would make things much easier if enums without backed type would just serialize to string and have (try)from to avoid that confusion.
But, anyways, when using backed enums we should probably always refer to the value instead of the key when (de)serializing the enum

@@ -3,6 +3,8 @@
'Neos.Neos:Node': true
'Neos.Neos:Hidable': true
abstract: true
strategy:
moveNode: RelationDistributionStrategy::STRATEGY_SCATTER
Copy link
Member

@bwaidelich bwaidelich Nov 13, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that's the root cause. Why not

Suggested change
moveNode: RelationDistributionStrategy::STRATEGY_SCATTER
moveNode: scatter

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This format is what we decided during the sprint when discussing the new setting. It is a lot clearer than only using the key

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The thing is: If it is clearer, we should change the values of those enums to reflect this, i.e. change

case STRATEGY_SCATTER = 'scatter';

to

case STRATEGY_SCATTER = 'STRATEGY_SCATTER';

(like we did for many other enums exactly to avoid that confusion).

But without that change, having a different serialization format wether it's in the database (or a JSON representation) from the YAML representation is just error prone in my eyes.

Anyways, I don't want to block this PR of course – feel free to ignore me, just my 2ct :)

@@ -7,6 +7,8 @@
'Neos.Neos:Hidable': true
abstract: true
aggregate: true
strategy:
moveNode: RelationDistributionStrategy::STRATEGY_GATHER_ALL
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

..and

Suggested change
moveNode: RelationDistributionStrategy::STRATEGY_GATHER_ALL
moveNode: gatherAll

Comment on lines 45 to 53
{
if (str_starts_with($name, 'RelationDistributionStrategy::')) {
$name = substr($name, strpos($name, '::') + 2);
foreach (self::cases() as $status) {
if ($name === $status->name) {
return $status;
}
}
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just realized that we use a different value for name and value.
btw that's IMO a limitation of PHP enums, it would make things much easier if enums without backed type would just serialize to string and have (try)from to avoid that confusion.
But, anyways, when using backed enums we should probably always refer to the value instead of the key when (de)serializing the enum

}
}
}
return self::STRATEGY_GATHER_ALL;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, one more addition:
If we decide to keep the value based serialization we should at least fail if referring to an invalid value, rather than falling back to some strategy

@@ -7,6 +7,8 @@
'Neos.Neos:Hidable': true
abstract: true
aggregate: true
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

aggregate is dead and can be removed :)

this is no longer a supported concept. The relationDistributionStrategy must be used instead for default move behavior

@@ -7,6 +7,8 @@
'Neos.Neos:Hidable': true
abstract: true
aggregate: true
strategy:
moveNode: RelationDistributionStrategy::STRATEGY_GATHER_ALL
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
moveNode: RelationDistributionStrategy::STRATEGY_GATHER_ALL
moveNode

could be relationDistribution

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

to make this a little easier, if we put it to options

options:
  relationDistributionStrategy: gatherAll

and access it via Neos\ContentRepository\Core\NodeType\NodeType::getOptions

@pKallert
Copy link
Contributor Author

To summarize our discussion from yesterday:

The Strategy will be set in the Neos UI depeding on NodeType when a node is moved.
The setting will be moved to options, not in "strategy"
Since the options are not as important, I can just chose the naming however I want to.
"aggregate" will be removed

@mhsdesign
Copy link
Member

Thanks for your adjustments, i also removed the aggregate=true part from the documentation and the NodeType class.
And as the Neos UI now evaluates alone options.moveNodeStrategy i moved the configuration to the Neos Ui package. (and we now use gatherAll instead of the ENUM name) :)

@mhsdesign mhsdesign changed the title Draft: FEATURE: Add nodeMove strategy configuration to nodetypes FEATURE: Add nodeMove strategy configuration to nodetypes Nov 19, 2024
@mhsdesign mhsdesign requested a review from kitsunet November 27, 2024 08:09
@mhsdesign
Copy link
Member

@kitsunet you said you want to test this? It would be really nice, otherwise ill experiment with it.

@kitsunet kitsunet merged commit 8ebf99c into neos:9.0 Nov 27, 2024
12 checks passed
@mhsdesign mhsdesign changed the title FEATURE: Add nodeMove strategy configuration to nodetypes TASK: Remove obsolete aggregate as Neos Ui handles nodeMove strategy now via special configuration Dec 1, 2024
@github-actions github-actions bot added the Task label Dec 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Archived in project
Development

Successfully merging this pull request may close these issues.

5 participants