IriStrategy.namedFactory constructor

Creates a reference to a named factory function for creating IRI mappers.

Use this constructor when you want to provide a factory function that creates IriTermMapper instances dynamically. This is particularly useful for libraries that need to coordinate IRI generation across multiple types with a single, shared configuration and strategy.

The factory function is called with the specific record type inferred from this class's @RdfIriPart annotations, and optionally a configuration object if configInstance is specified. This allows a single factory to handle different classes while maintaining type safety.

When using this approach, you must:

1. Implement a factory function with the appropriate signature
2. Provide the factory function as a named parameter to initRdfMapper

This approach is ideal for:

• Libraries that need to coordinate IRI generation across all stored types
• Pod-based storage systems where IRI allocation requires coordination

Important: When using custom factories with multiple IRI part properties, use @RdfIriPart.position(index) to specify the order of fields in the record that will be passed to your factory-created mapper.

Factory Function Signatures

The generated factory function signature depends on whether configInstance is provided:

Without configuration:

IriTermMapper<RecordType> Function<T>() factoryName

With configuration:

IriTermMapper<RecordType> Function<T>(ConfigType config) factoryName

Where RecordType is inferred from the @RdfIriPart annotations on this specific class, T is the class of the resource being mapped, and ConfigType is the type of the configuration object.

Examples

Simple factory without configuration:

@RdfGlobalResource(Person.classIri, IriStrategy.namedFactory('podIriFactory'))
class Person {
  @RdfIriPart()
  final String id;
  // ...
}

// Factory function with generic type parameter:
IriTermMapper<(String,)> createIriMapper<T>() {
  return IriStrategyMapper<(String,)>(targetType: T, coordinator: globalPodCoordinator);
}

final rdfMapper = initRdfMapper(podIriFactory: createIriMapper);

Factory with configuration:

@RdfGlobalResource(
  Document.classIri,
  IriStrategy.namedFactory('podIriFactory', PodConfig(storagePolicy: 'distributed'))
)
class Document {
  @RdfIriPart.position(1)
  final String documentId;
  // ...
}

// Factory function with generic type parameter and config:
IriTermMapper<(String,)> createIriMapper<T>(PodConfig config) {
  return DocumentIriMapper<(String,)>(
    targetType: T,
    // podCoordinator would be available in the scope where the factory is defined
    coordinator: podCoordinator,
    storagePolicy: config.storagePolicy
  );
}

final rdfMapper = initRdfMapper(
  podIriFactory: createDocumentIriMapper,
  // Note: podConfig is embedded in generated code, not passed here
);
// Generated code within initRdfMapper calls `podIriFactory<Document>(PodConfig(storagePolicy: 'distributed'))`
// and provides the returned mapper to the Document resource mapper

The factory approach enables sophisticated coordination strategies while maintaining the simplicity of annotation-driven configuration. The factory function can access shared resources, configuration, or coordination services to ensure consistent IRI allocation patterns across your application.

The optional providedAs parameter allows this resource's IRI to be provided to dependent mappers under the specified name, enabling hierarchical IRI patterns.