You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A method could be created for each of the types so that the logic for determining which string to return would be come the responsibility of the type itself rather than the caller.
This feels like more of a framework code generation issue than something to solve within specification code as I don't think the specification should know or understand SDK-specific details (e.g. types.BoolType). Generating terraform-plugin-go code, for another example, would be concerned with understanding tftypes package implementation details.
One potential way to envision this on the framework side of things is having a wrapper type, similar to the schema wrapper types, that knows how to handle the framework-specific details:
// In terraform-plugin-codegen-framework/internal/schema package since// it should theoretically be generic across any schema type.package schema
typeBoolTypestruct {
CustomType*schemaspec.CustomType// or its own type, if there's shared framework-specific details worth abstracting
}
func (tBoolType) SchemaDefinition() string {
ift.CustomType!=nil {
returnt.CustomType.Type
}
return"types.BoolType"
}
func (tBoolType) SchemaImport() string {
ift.CustomType!=nil {
ift.CustomType.HasImport() {
returnt.CustomType.Import
}
return""
}
return"github.com/hashicorp/terraform-plugin-framework/types"
}
In the terraform-plugin-codegen-framework code strings for the types for use in generated schema are produced along the following lines:
A method could be created for each of the types so that the logic for determining which string to return would be come the responsibility of the type itself rather than the caller.
For instance:
The text was updated successfully, but these errors were encountered: