Discussion: Default dimension / default context in the new CR

[mhsdesign]

Neos 9 says that there is no default context, and for most cases this is perfectly valid as most times context exists by having a $node at hand. But there might be the occasion that one wants and arbitrary dsp (as workaround for https://github.com/neos/neos-development-collection/issues/4830) or that one wants to display a selectbox in a backend module listing all the possible options with the default one first.

While one could hardcode these things to a specific language, or in projects without dimension to DimensionSpacePoint::withoutDimensions() i thing this is a bad idea and should not promoted much.

    private function getDefaultContentSubgraph(): ContentSubgraphInterface
    {
        // This is hard-coded to use the "default" content repository to keep things simple
        $contentRepository = $this->contentRepositoryRegistry->get(ContentRepositoryId::fromString('default'));
        // And we are only interested in nodes from the "live" workspace
        return $contentRepository->getContentGraph(WorkspaceName::forLive())->getSubgraph(
            // ...and this is hard-coded to the default dimension of the Neos.Demo package!
            DimensionSpacePoint::fromArray(['language' => 'en_US']),
            // ...and we load disabled nodes, too, since we're in a backend module
            VisibilityConstraints::withoutRestrictions()
        );
    }

instead there are several ways to determine a possible dsp combination or in the Neos.Neos context one could use the default one configured for a Neos site. See \Neos\Neos\Domain\Model\SiteConfiguration::$defaultDimensionSpacePoint:

$site->getConfiguration()->defaultDimensionSpacePoint;

but do we want to use the site for that? Is this intended?

This is discussed in the following slack threads:

• In the new CR, who would be the authority on providing a default dimension space point?

• getContentDimensionsOrderedByPriority vs getRootGeneralizations