Framework: Tokens can be converted to strings #518
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,28 @@ | ||
| import { DEFAULT_ENGINE_NAME, ProvisioningEngine, StringFragment } from "../core/engine-strings"; | ||
|
There was a problem hiding this comment. This whole “provisioning engine framework” feels like it’s future proofing for something we really don’t know how to design yet. May I suggest that the token plugin system will be kept within the confines of the “tokens framework” and use domain-specific semantics. For example, if the CDK will be used to synthesize pure Amazon State Language documents, then there is no provisioning engine involved, but there still might be tokenization heuristics. Quite possibly, we might want to extract the tokens framework into a separate general-purpose and independent npm module, unrelated to cloud resource provisioning. There was a problem hiding this comment. Well I did have it all in one file first, but it became quite large and mixed too many different concerns for my tastes. I just need some place to put this logic which is preferably a separate file, so it is "string handling for engines in an IoC fashion", which is this.
Regardless of the language that is being stringified (ASL or otherwise), if there is Token stringification to be done it will involve stitching string literals and intrinsics together. This must be done with an engine-specific If you use Amazon State Language on Terraform, we need Granted, maybe the filename is not fantastic here, and maybe the interface could be replaced with a single function, but that's about all the undesigning leeway we have. There was a problem hiding this comment. I am not referring to the case where some other provisioning engine is used, I am referring to the case where the CDK is used to just synthesize other types of documents. I agree, tokenization/concat will still need to happen in those cases, but the provider will not be a "provisioning engine" but some other document format. That's why I suggested to bind this terminology to the resolve/tokens domain and not to the resource provisioning domain. Then perhaps some of the abstractions will be an overkill. For example |
||
| import { IntrinsicToken } from "../core/tokens"; | ||
|
|
||
| /** | ||
| * The default intrinsics Token engine for CloudFormation | ||
| */ | ||
| export const CLOUDFORMATION_ENGINE = 'cloudformation'; | ||
|
|
||
| /** | ||
| * Base class for CloudFormation built-ins | ||
| */ | ||
| export class CloudFormationIntrinsicToken extends IntrinsicToken { | ||
| protected readonly engine: string = CLOUDFORMATION_ENGINE; | ||
|
There was a problem hiding this comment. Instead of using a string value for There was a problem hiding this comment. It's not a But I guess I'm with ya on them having a direct reference to the engine, instead of indirected through a string pointing to a table. |
||
| } | ||
|
|
||
| import { FnConcat } from "./fn"; | ||
|
|
||
| const cloudFormationEngine = { | ||
| /** | ||
| * In CloudFormation, we combine strings by wrapping them in FnConcat | ||
| */ | ||
| combineStringFragments(fragments: StringFragment[]) { | ||
| return new FnConcat(...fragments.map(f => f.value)); | ||
| } | ||
| }; | ||
|
|
||
| ProvisioningEngine.register(CLOUDFORMATION_ENGINE, cloudFormationEngine); | ||
| ProvisioningEngine.register(DEFAULT_ENGINE_NAME, cloudFormationEngine); | ||
|
There was a problem hiding this comment. We used to at some point because we could at some point stitch values together where none of them would be an intrinsic (and so it would not be obvious which engine to use) but I guess at this point that's something I can do in the framework. |
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This wraps a token and
CloudFormationJSON.stringifyalso returns aToken. Can we eliminate one layer?