Namespace Serenity.StructuredPersistence.Infrastructure.Editor.Authoring

Classes

SettingsAssetAuthoring

Shared, engine-side (non-IMGUI) plumbing every single-settings-asset creation wizard needs: resolving the project-wide settings asset (explicit path, single existing asset, or none), Assets-path shape validation, recursive folder creation with a rollback-friendly created-paths trail, and a hardened asset-write check. Extracted from Serenity.GameProgress.Infrastructure.Editor.Builder.GameProgressCreator and Serenity.GameSave.Infrastructure.Editor.Builder.GameSaveCreator, which were byte-for-byte duplicating this exact logic. Serenity.Leaderboard.Infrastructure.Editor.Builder.LeaderboardCreator keeps its own private copy — it also resolves board uniqueness and a view/menu-option tree this shared helper knows nothing about, and touching its already-tested code is out of scope for this extraction.

SettingsAssetAuthoring.SettingsResolution<TSettings>

Where a settings asset of type TSettings was found, if anywhere.

SettingsAssetResolution

Resolve-or-create for a settings asset identified BY ID WITHIN A FOLDER — the shape every creator that authors many assets of one type needs, and the counterpart to ResolveSettingsContext<TSettings>(string), which answers the opposite question: where is the ONE project-wide settings asset?

Replaces the byte-identical private helper WaveCreator, SequencePlayerCreator and PlayerInputCreator each declared, plus the concrete twins in InitializationPipelineProfileCreator and LoggingProfileCreator. Those five differed only in whether the fallback file name arrived as a parameter or as a class constant.

Lives beside SettingsAssetAuthoring rather than beside Serenity.Global.Infrastructure.Editor.SerenityAssetIdLookup because it needs EnsureProjectFolderExists(string, ICollection<string>) and VerifyAssetWasWrittenToDisk(string), and this assembly already depends on the one those two lookups live in — the reverse would be a cycle. Reaching past EnsureProjectFolderExists to the EnsureFolder it wraps would drop its Assets-path-shape guard, which for some callers is the only validation the path gets.

StructuredBackendAuthoringFactory

Engine-side (non-IMGUI) half of the shared backend authoring step: per-kind connection defaults, validation, and shared backend asset construction. Extracted from Serenity.Leaderboard.Infrastructure.Editor.Builder.LeaderboardCreator so the GameSave and GameProgress creation wizards do not each duplicate this logic a second and third time; Leaderboard's own copy is left untouched to avoid touching its already-tested code.

StructuredBackendAuthoringFields

Every connection field any StructuredBackendAuthoringKind backend asset can carry. A wizard window holds one of these as a [SerializeField] and hands it to StructuredBackendAuthoringGui/StructuredBackendAuthoringFactory, so the shared backend authoring step (cards, fields, validation, asset construction) is written once instead of duplicated per consumer wizard (GameSave, GameProgress). Table/collection name is deliberately NOT here — it belongs to the consumer's own settings asset, not to the backend.

StructuredBackendAuthoringGui

The shared IMGUI half of the backend authoring step: the four backend cards, the kind-specific fields, and the scripting-define/secret-in-plaintext warnings — extracted from CreateLeaderboardWindow's Backend step so the GameSave and GameProgress wizards draw the identical UI without duplicating it. Pure presentation over StructuredBackendAuthoringFields; all validation and asset construction live in StructuredBackendAuthoringFactory.

Structs

StructuredBackendAuthoringFactory.KindDefaults

Per-kind connection defaults offered by a wizard's Backend step, keyed by StructuredBackendAuthoringKind.

Enums

StructuredBackendAuthoringKind

Editor-only authoring choice shared by every structured-store consumer's creation wizard (GameSave, GameProgress): which shared UnityStructuredBackendDefinition subtype the wizard creates and assigns to the consumer's settings asset. Purely a wizard concern — the runtime always dispatches on the backend asset's concrete type, never on this enum. Every kind creates an explicit backend asset, including PlayerPrefs.