For advanced use of the template studio and code generator, I would like to be able to include a template dynamically. I mean the following: beeing able to write something like this:

<# <%=_currentConfiguration.GetTemplateId();%> #>

I understand I am nesting here an output code snippet inside a include template statement and that it does not work but it gives you the idea of what I am trying to achieve.

I understand that include statements are run in preprocessing phase and that will not help in trying to achieve the above...

Any idea how I could achieve this? in this version of template studio or later 3.0?

Thanks in advance Kind Regards Walter Almeida

Could you give a use case description?

Otis wrote:

Could you give a use case description?

Case description:

I have extra metadata, including a list of methods I want to generate on a given set of classes. Theses methods are defined in templates so that they can apply on all the classes + provide modularity by allowing to add (or inject) new methods in a configurable way + diminish the complexity of templates by breaking done into multiple templates.

I could use [if/else] block to control the inclusion of templates, however I will loose a bit the modularity since for any new method template I want to add, I would have to include one more [if/else] statement with the new method template inclusion in the main template. Instead of that I want to be able to do the following: loop on all the methods configured for generation on my main template, and for all these methods, include the proper template:

<%foreach (_currentMethodDefinition in _myObject.MethodDefinitions) {%> <# <%=_currentMethodDefinition.TemplateId%> #> <%}%>

Is it clear enough?

Kind Regards, Walter Almeida

WHy not use an include template which specifies includes ? So per method you want to inject, you have an include template and which is bound to its own id. Then you create a template which just includes these ids, and THAT template you include in the main template.

If you then don't want to include a method anymore, remove the binding. If you want to add a method template, add the binding, add the include to the includes containing template and you're done (so no extra config files). BUt perhaps I miss something...

Hi Frans,

I do not want to generate the same list of methods for all my classes, but generate a specific set of methods for each class, depending on some metadata:

For each entity, or typelist, I want to generate a set of classes and the classes to be generated will be controled by some configuration data. And depending on the configuration, I want to generate an additionnal set of methods on each of the classes. Meaning that a static include template listing all the template Ids for every method is not satisfactory since I don't know in advance which methods will have to be generated and the list of methods might differ from one class to another (not all the methods will have to be generated for all the classes.).

That was the reason for wanting to do some kind of "dynamic" template inclusion. Or try to find an alternate solution... This "dynamic" template inclusion would be a mean to do some advanced "modular" code generation by generating and composing classes from chunk of classes and method definitions...

Hope I am clear enough!!

Kind Regards Walter Almeida

Ok I see what you mean. the template system itself doesn't allow that to happen through the normal channels, i.e. there are bindings, bindings are interpreted, tasks are ran, templates are looked up in the bindings, parsed, interpreted and output is created. Lpt templates are also compiled all before the first task is ran, so that too makes things not possible the way you see it.

However, you can take advance of how things are compiled of course: all lpt templates are all compiled into 1 assembly, and each template ends up as a class with the templateid as the name. (I ran into a tiny issue with this, with v3 there's a small addition, but that's not major). So instead of including templates at the spot, you can also call into a template's method which emits what you want.

So instead of including the code dynamically, you have each method in 1 template (so 1 template with all the methods), then in your meta-data you call into that template, the emit method which will emit the code you want to include at that spot. This to me is equal to including a template at runtime.

Does this make sense or do I overlook something?

Hello Frans,

Sorry for my late reply. I am actually on holiday and therefore not following the forum everyday.

Otis wrote:

So instead of including the code dynamically, you have each method in 1 template (so 1 template with all the methods), then in your meta-data you call into that template, the emit method which will emit the code you want to include at that spot. This to me is equal to including a template at runtime.

Does this make sense or do I overlook something?

I think I see what you mean. However I will have to try to make sure I get it. In these methods that would be part of the single template file and would emit code: can I have the same mix of output code and control code as I have in regular templates?

I agree it would solve my problem however maybe not in the most natural way. It gives me a good starting point to see what I can do.

Thanks Kind Regards, Walter Almeida

Walter wrote:

Otis wrote:

So instead of including the code dynamically, you have each method in 1 template (so 1 template with all the methods), then in your meta-data you call into that template, the emit method which will emit the code you want to include at that spot. This to me is equal to including a template at runtime.

Does this make sense or do I overlook something?

I think I see what you mean. However I will have to try to make sure I get it. In these methods that would be part of the single template file and would emit code: can I have the same mix of output code and control code as I have in regular templates?

No, that's a bit of a problem. you've to use write calls. As it's about emitting calls to methods, I don't think that's much of a problem.

Otis wrote:

No, that's a bit of a problem. you've to use write calls. As it's about emitting calls to methods, I don't think that's much of a problem.

Ah ok... Then I see exactly what you mean. However I need to generate more than just calls to methods. In fact I want to generate full methods implementations. And I don't want to include these method definitions in the main class template because I want to conditionnaly generate these methods + I want a flexible way to define new methods (full method definition with body). This is to achieve what I would call "modular" modelling and code generation and the ability to model and generate classes from "chunks" of models/classes ...

Humm... I probably want to do too much... I will keep thinking how to do it or how to do it differently...

Thanks for help. Walter