-
-
Notifications
You must be signed in to change notification settings - Fork 223
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
TASK: Remove obsolete aggregate
as Neos Ui handles nodeMove strategy now via special configuration
#5314
Conversation
There was a problem hiding this 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 :)
Neos.ContentRepository.Core/Classes/Feature/NodeMove/Command/MoveNodeAggregate.php
Outdated
Show resolved
Hide resolved
Neos.ContentRepository.Core/Classes/Feature/NodeMove/Dto/RelationDistributionStrategy.php
Outdated
Show resolved
Hide resolved
Co-authored-by: Sebastian Kurfürst <[email protected]>
…com/pKallert/neos-development-collection into feature/nodeMove-strategy-by-config
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 ... |
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. 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. |
Thanks a lot for the great explanation! 🤩 |
{ | ||
if (str_starts_with($name, 'RelationDistributionStrategy::')) { | ||
$name = substr($name, strpos($name, '::') + 2); | ||
foreach (self::cases() as $status) { | ||
if ($name === $status->name) { | ||
return $status; | ||
} | ||
} | ||
} |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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
moveNode: RelationDistributionStrategy::STRATEGY_SCATTER | |
moveNode: scatter |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
..and
moveNode: RelationDistributionStrategy::STRATEGY_GATHER_ALL | |
moveNode: gatherAll |
{ | ||
if (str_starts_with($name, 'RelationDistributionStrategy::')) { | ||
$name = substr($name, strpos($name, '::') + 2); | ||
foreach (self::cases() as $status) { | ||
if ($name === $status->name) { | ||
return $status; | ||
} | ||
} | ||
} |
There was a problem hiding this comment.
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; |
There was a problem hiding this comment.
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
Neos.ContentRepositoryRegistry/Resources/Private/Schema/NodeTypes.schema.yaml
Outdated
Show resolved
Hide resolved
@@ -7,6 +7,8 @@ | |||
'Neos.Neos:Hidable': true | |||
abstract: true | |||
aggregate: true |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
moveNode: RelationDistributionStrategy::STRATEGY_GATHER_ALL | |
moveNode |
could be relationDistribution
There was a problem hiding this comment.
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
To summarize our discussion from yesterday: The Strategy will be set in the Neos UI depeding on NodeType when a node is moved. |
Thanks for your adjustments, i also removed the |
@kitsunet you said you want to test this? It would be really nice, otherwise ill experiment with it. |
aggregate
as Neos Ui handles nodeMove strategy now via special configuration
As the Neos ui now uses
options.moveNodeStrategy
to determine whether to move all nodes or just on dimension: neos/neos-ui#3876And we discussed that we DONT want to make that dependant on
aggregate: true
in the core like in 8.3And the fact that
aggregate
is now fully unused and its description and docs are outdated we removed the unusedaggregate
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
FEATURE|TASK|BUGFIX
!!!
and have upgrade-instructions