In earlier versions we could access the connectionstring using _executingGenerator.ProjectDefinition.ConnectionString but this is no longer present. Where is this property now, and in which help file are these properties documented?

Cheers, Jason

From app.config template:

<%=currentProject.CreateConnectionStringKeyNameForDatabase(_executingGenerator.DriverID)%>"

In general please consult the designer reference manual for details regarding the object model the templates work with. And in a lot of cases things have already been done somewhere in a template, e.g. for EF, Linq to Sql or NHibernate, we use lpt templates only, so the code to access the object model at runtime and produce a piece of specific output is available in these templates, as examples. It's of course undoable to read all the templates, but it works best if you e.g. see a piece of output in the generated code for e.g. EF and want to do something like that but a bit different, you can go to the template producing that file and copy the part which produces that snippet.

But in short, the designer reference manual is a good start. Also we created GeneratorUtils which is a class which produces a variety of information for template code to make things easier.

Otis wrote:

<%=currentProject.CreateConnectionStringKeyNameForDatabase(_executingGenerator.DriverID)%>"

In general please consult the designer reference manual for details regarding the object model the templates work with.

Thanks Otis. I do generally search through existing code examples to find features I require, but in a case like this where I'm implementing something not in any template, I generally check the help file for detailed information on object properties and methods. So when I call CreateConnectionStringKeyNameForDatabase() I don't get back a password, even though it's in the project's XML definition. I then search the help for "CreateConnectionStringKeyNameForDatabase" but get no match, likewise for "GeneratorUtils".

Essentially, I'd like to know if these features are documented and I'm missing it, or do I keep posting "How do I do this" questions ? I eventually found the web page of how to integrate custom templates (I was making up a template ID, rather than using a predefined string), so what I require is almost completed. Why would you ever create a custom TemplateID? If you don't, for sanity's sake might it be better to have the IDs as a dropdown?

Cheers, Jason

JSobell wrote:

Otis wrote:

<%=currentProject.CreateConnectionStringKeyNameForDatabase(_executingGenerator.DriverID)%>"

In general please consult the designer reference manual for details regarding the object model the templates work with.

Thanks Otis. I do generally search through existing code examples to find features I require, but in a case like this where I'm implementing something not in any template, I generally check the help file for detailed information on object properties and methods. So when I call CreateConnectionStringKeyNameForDatabase() I don't get back a password, even though it's in the project's XML definition.

Are you sure? We don't save passwords in the project file. So the connection string produced never contains a password (the app.config generated by the templates doesn't either). There's a 'password' connection element in the xml file, but it's never filled with a value. So generating a connection string is never going to contain the password.

I then search the help for "CreateConnectionStringKeyNameForDatabase" but get no match, likewise for "GeneratorUtils".

It's not in the user help, it's in the designer reference manual, which you can download from the website. Using the index you can find GeneralUtils just fine. Please download it under Documentation: LLBLGen Pro v4.2 designer / algorithmia assemblies reference manual

Essentially, I'd like to know if these features are documented and I'm missing it, or do I keep posting "How do I do this" questions ?

The basic mechanism how a template works is documented (in the SDK docs), and the object model that's accessible in a template is documented (in the reference manual). So in the template you can do whatever you want with the document model exposed through 'Project' and other classes. So it comes down a bit like with the .NET BCL: you want to do XYZ, but don't know which class to use for that or which method, and you have to look for it a bit. We can't make that easier as we don't know what you're looking for in advance

But it's not that bad, things are pretty straight forward: you start with the project class and in general there's a method that gives you want you want or parts of it so you can e.g. transform that to the info you need at runtime. The GeneratorUtils are helpers which can produce information in a more straightforward manner, this is especially useful with relationships as it would otherwise be required to read information from multiple sources which would be more work.

I eventually found the web page of how to integrate custom templates (I was making up a template ID, rather than using a predefined string), so what I require is almost completed. Why would you ever create a custom TemplateID? If you don't, for sanity's sake might it be better to have the IDs as a dropdown? Cheers, Jason

The templates we ship include templates with a specific ID which are prefixed with 'Custom'. A user can bind a template to these and they're then included at generation time.

It's not doable to show a dropdown, as we don't know which templateIDs are live at design time: templatebindings define the templateID-file combinations, and it depends on e.g. which .net platform and which framework you've chosen which templatebindings files are loaded. This is decided when you generate code, not when you design / develop the template bindings. It's very flexible, but indeed can be a bit daunting when you start with it.

TemplateIDs are the keys of which template to use at a given moment. If you define your own preset where you specify which templateid to use with which task, you can make up whatever ID you want: as long as it's present in a templatebindings file at generation time, there will be a file found to use so it will work. If you want to include the template into another template, the ID you're using for your template file has to be the one specified in the include statement in the including template (otherwise it doesn't know what to include ).

TemplateIDs are a language generic way to work with files: what file is bound to the template and ultimately used depends on which templatebindings file is used. It's then easy to switch between languages without changing everything else or override a template file by simply choosing another templatebindings file with a binding for the same templateID but to a different file to be with a higher precedence (second tab in the generator configuration dialog).

OK, that clarifies things for me, thanks. I have to say that of all the ORM systems I've used over the years, LLBLGen has the most features, most complexity, most documentation, and most efficient support. The most tricky thing I find is wading through documentation to find references to the things I want

Cheers, Jason

Thanks Jason