Affected Version
All versions of this module and SilverStripe
Description
This GridField component allows some pretty advanced functionality; namely, the ability to manually sort items regardless of the type of relation, which is extremely handy. The one major drawback that I've noticed is that if you're attempting to augment/manipulate that relation from any other context then sorting is not handled at all. At least, not until the CMS user happens to navigate to view/load the grid field, at which point there could be unpredictable behavior.
See below for an example.
Steps to Reproduce
For example (this happens to be my use case): Say you have a many-to-many relation from a HomePage which features multiple StoryArticle objects. From the context of the StoryArticle you might want to enable/disable featuring to the HomePage via a checkbox. However, you also need to have explicit and manual control over the sorting of items which get featured there (i.e. via GridField and this component). Also, logically, the idea in this scenario that the act of featuring an article will place this object at the top, thus ->append_to_top is set to true, however this is done from the context of the GridField component.
However, if the user checks the box to feature the story on the homepage, the association will be created, but the sort field (e.g. Sort on the pivot HomePage_FeaturedStoryArticles.Sort) will remain 0 until the user happens to navigate to view the GridField in the CMS, which may be in a completely different area. This is particularly problematic if multiple are configured this way over time and now multiple will sit at 0 and then will be reordered only once the GridField is viewed. This is the "unpredictable" behavior mentioned above, as the sorting result at this point may choose a different order (derived from ID and Created, for example) which may not align with the actual order in which these items were actually associated in time.
Recommendation
Abstract the logic which handles the sorting sufficiently such that it can also be implemented either by an extension or at least called statically (e.g. SortableGridField::fixSortRelation($owner, $relationList) or similar). This would allow operations to occur that aren't tightly coupled to a UI layer like GridField such as in the example scenario above.
Affected Version
All versions of this module and SilverStripe
Description
This GridField component allows some pretty advanced functionality; namely, the ability to manually sort items regardless of the type of relation, which is extremely handy. The one major drawback that I've noticed is that if you're attempting to augment/manipulate that relation from any other context then sorting is not handled at all. At least, not until the CMS user happens to navigate to view/load the grid field, at which point there could be unpredictable behavior.
See below for an example.
Steps to Reproduce
For example (this happens to be my use case): Say you have a many-to-many relation from a
HomePagewhich features multipleStoryArticleobjects. From the context of theStoryArticleyou might want to enable/disable featuring to theHomePagevia a checkbox. However, you also need to have explicit and manual control over the sorting of items which get featured there (i.e. viaGridFieldand this component). Also, logically, the idea in this scenario that the act of featuring an article will place this object at the top, thus->append_to_topis set totrue, however this is done from the context of the GridField component.However, if the user checks the box to feature the story on the homepage, the association will be created, but the sort field (e.g.
Sorton the pivotHomePage_FeaturedStoryArticles.Sort) will remain0until the user happens to navigate to view theGridFieldin the CMS, which may be in a completely different area. This is particularly problematic if multiple are configured this way over time and now multiple will sit at0and then will be reordered only once theGridFieldis viewed. This is the "unpredictable" behavior mentioned above, as the sorting result at this point may choose a different order (derived fromIDandCreated, for example) which may not align with the actual order in which these items were actually associated in time.Recommendation
Abstract the logic which handles the sorting sufficiently such that it can also be implemented either by an extension or at least called statically (e.g.
SortableGridField::fixSortRelation($owner, $relationList)or similar). This would allow operations to occur that aren't tightly coupled to a UI layer likeGridFieldsuch as in the example scenario above.