Hi Joel,
What exactly failed from your initial attempt?
See, this is copied from SDK Documentation:
TDL itself is a simple language, with 2 constructs and various 'tags' which represent a value in the current context. TDL is a pattern matching language, which means that it doesn't contain the ability to specify expressions. The reason for this is that the language itself is very easy to use and doesn't cause a lot of syntax errors in TDL statements. If the token found is not understood or not well formed, it is skipped as a token and seen as part of the text the tokens are placed in. This means you can find errors very easily: the tokens which are wrong are emitted in the generated code, because what's not recognized as a token or is an erroneous statement, is seen as plain text and is emitted directly into the destination file.
For Camel things you can use the token you mention:
<[CaseCamel NameSingleTokenStatement]>
For detailed explanation of the TDL Grammar, see the SDK docs. If you need some sort of special helper functions, you should consider to use LPT template system:
.lpt templates are templates written in VB.NET or C# which are parsed and executed by the DotNetTemplateEngine task performer and which result in whatever output is formulated in the templates. As with TDL templates, Lpt (LLBLGen Pro Template) templates are also bound to templateids through templatebindings files. TDL is the language of choice for the templates which are used to generate the code build on top of the LLBLGen Pro runtime libraries, but .lpt templates are preferred when it it comes to code generation which requires access to the complete project contents and for code generation tasks for which TDL is too limited. TDL though is powerful with its simplicity: a single statement can represent a lot of logic, logic which would otherwise require a lot of code inside the templates. So** if you want fine-grained control, .lpt templates are for you**, but at the same time it might require more code to write inside the templates and because of the lower-levelness of the template logic, it might also result in more time being spend on debugging the templates.
