Just looking for some advice.

I have 2 requirements, 1 is that I need to flag entity classes so that I can access all flagged entities from Template Studio. The intent is so that all flagged entities can be found using Template Studio, then I can create a class exposing the flagged entites, making them accessible as a collection from the class generated by Template Studio. Basically, I want to use template studio to create a LookupEntityClass that exposes all flagged entities as collections.

I was considering saving all flagged entities into an XML DOM then parsing the DOM via an assembly written to read the DOM and access the assembly via template studio. Another more saavy approach, IMO, would be to flag all entities with a custom attribute, so that when they are code generated they are code generated with the attribute in place.

Requirement 2 is along the same lines, except that I want to be able to create a DomainObject that is a grouping of entity managers. For example, I use the manager templates to create manager classes, so now I want to make a subset of manager classes avaialbe in the DomainObject so when developers are working with a sub system, they simply use the managers exposed via the DomainObject.

I was thinking that the same principal could apply to the plugin. Either save flagged entities in an xml file or use attributes.

Does anyone else have any thoughts about how to best go about this?

After doing some research on plugins, all I can say at this point is wow Frans, great job.

I can see how to access all entities that were selected and loop through them. I think I just need to access the UserCodeRegion of an entity and add an attribute there. Then when I compile the generated code, it should be marked with the attributes inserted into user code regions.

Then I can parse the assemblies using teplate studio and pick out the entity classes that have been flagged with the attribute.

However, I cannot seem to get at a user code region using an EntityDefinition object. Is there some other way to access a UserCodeRegion?

Devildog74 wrote:

Just looking for some advice. I have 2 requirements, 1 is that I need to flag entity classes so that I can access all flagged entities from Template Studio. The intent is so that all flagged entities can be found using Template Studio, then I can create a class exposing the flagged entites, making them accessible as a collection from the class generated by Template Studio. Basically, I want to use template studio to create a LookupEntityClass that exposes all flagged entities as collections.

I think the best way to do this is by adding a custom property. If you run the code generation from llblgen you can also use a plugin to simply 'tag' entities and read the tag values in the template. The tag values aren't saved into the project file so that option is only working if you run the code generator from the designer.

Devildog74 wrote:

After doing some research on plugins, all I can say at this point is wow Frans, great job.

.

and it was relatively easy to do as well. When I throw out the magic lib in favor of janus' tab controls with mdi, I can also offer windowed plugins

I can see how to access all entities that were selected and loop through them. I think I just need to access the UserCodeRegion of an entity and add an attribute there. Then when I compile the generated code, it should be marked with the attributes inserted into user code regions.

Then I can parse the assemblies using teplate studio and pick out the entity classes that have been flagged with the attribute.

However, I cannot seem to get at a user code region using an EntityDefinition object. Is there some other way to access a UserCodeRegion?

I think the best way to do this is to add an include template into the entities and in that include template create a usercode region with the values.

In a template you can do this though: (lpt)

string usercoderegion = DotNetTemplateEngine.GetUserCodeRegion("Testregion", "//");

which grabs the Testregion user code region if it's exists, otherwise it creates a new one.

Otis wrote:

I think the best way to do this is by adding a custom property. If you run the code generation from llblgen you can also use a plugin to simply 'tag' entities and read the tag values in the template. The tag values aren't saved into the project file so that option is only working if you run the code generator from the designer.

So, if I write code in the execute method of the plugin to modify the Tag member of an EntityDefinition, the values in that member will be accessible in lpt when the code generation is run from the LLBLGen IDE?

Devildog74 wrote:

Otis wrote:

I think the best way to do this is by adding a custom property. If you run the code generation from llblgen you can also use a plugin to simply 'tag' entities and read the tag values in the template. The tag values aren't saved into the project file so that option is only working if you run the code generator from the designer.

So, if I write code in the execute method of the plugin to modify the Tag member of an EntityDefinition, the values in that member will be accessible in lpt when the code generation is run from the LLBLGen IDE?

Correct

the Tag values aren't saved, so you run the plugin, then generate code and it works. If you run the plugin, save, go to templatestudio, run code generation from there, it doesn't work. If you want to use the second scenario I think a custom property would be better.

So far so good, plugins rock; I have a few questions still.

With regards to task performers and the emitType set to generic; does this setting render the "_activeObject" member of an LPT Template not available?

Is it possible to launch the generator from the execute method of the plugin, using a task performer & template set pre-set by the plugin settings tab?

Is it possible to access the "Project Element Group" (specifically the name in the drop down list) from LPT?

Can you clarify the XML that needs to go into the task performer to enable debugging in an lpt template or are these just xml attributes that need to be set on the first "task" element that uses the DotNetTemplateEngine?

Devildog74 wrote:

So far so good, plugins rock; I have a few questions still.

With regards to task performers and the emitType set to generic; does this setting render the "_activeObject" member of an LPT Template not available?

Yes. _activeObject is set in a loop inside the template execution engine. This is thus the case when you specify an emit type like allEntities: it will then loop over all entities, for each entity it will call the template, setting _activeObject.

With 'generic' it simply calls the template, it's not looping over anything, so when the template finishes, the cycle is over for that task and the task is done.

Is it possible to launch the generator from the execute method of the plugin, using a task performer & template set pre-set by the plugin settings tab?

You should peek into the CliGenerator sourcecode how a set of tasks is started. If you copy that routine to your plug-in, you should be able to generate code from a plugin indeed. You can't call into the start routine inside the designer. But that's not a big problem, as the vast majority of the code is in the Generator object.

The plugin gets the ApplicationConfiguration object with the driver configs and all paths, it just has to load the generator config and the template set and that's about it.

Is it possible to access the "Project Element Group" (specifically the name in the drop down list) from LPT?

Yes, Project.ProjectElementGroups (hashtable, key groupname, value: ProjectElementGroup)

Can you clarify the XML that needs to go into the task performer to enable debugging in an lpt template or are these just xml attributes that need to be set on the first "task" element that uses the DotNetTemplateEngine?

Yes, just on the first task element which uses an lpt template, it's a parameter to the DotNetTemplateEngine, to switch it into debug build mode. There is a task defined for that in template studio.

If I wanted to package multiple plugins into one assembly can I do this?

If I want to make my plugins communicate with an RDBMS or something, can I do that too? For example, I might want to have settings saved in a DB and reloaded by the plugin when it runs.

If my plugin uses additional dlls like UI dlls for various controls and whatnot, where should they be deployed and if I am using infragistics will there be a conflict with the LLBLGen Designer?

When I finish my first plugin can I publish it to the svn repository for others to see and use?

Devildog74 wrote:

If I wanted to package multiple plugins into one assembly can I do this?

Yes, it enlists each plugin separately. It examines all types in an assembly in the plugin folder.

If I want to make my plugins communicate with an RDBMS or something, can I do that too? For example, I might want to have settings saved in a DB and reloaded by the plugin when it runs.

Yes. In the project, the driver object is available. You can create a connection string using the driver using this code: (in the plugin class)

string connectionString = base.ProjectToTarget.DatabaseDriver.ConstructConnectionString(base.ProjectToTarget.ConnectionElements);

The driver itself doesn't provide an interface for you to call into the db, you have to add that code to your plugin.

If you're really into it, you can create a popup form in which you add the connection control in the driver to retrieve new connection data.

If my plugin uses additional dlls like UI dlls for various controls and whatnot, where should they be deployed and if I am using infragistics will there be a conflict with the LLBLGen Designer?

Add them to one of the folders mentioned in the llblgen pro .config file, for example in the ReferencedAssemblies folder. If you're using a different version of the infragistics controls, it will be fine, as that's just that, a different version . If you use the same version, that's fine too.

When I finish my first plugin can I publish it to the svn repository for others to see and use?

Of course!

Otis wrote:

You should peek into the CliGenerator sourcecode how a set of tasks is started. If you copy that routine to your plug-in, you should be able to generate code from a plugin indeed. You can't call into the start routine inside the designer. But that's not a big problem, as the vast majority of the code is in the Generator object.

The plugin gets the ApplicationConfiguration object with the driver configs and all paths, it just has to load the generator config and the template set and that's about it.

I was wondering if you could point me in the right direction as to where to find this source code and what method I might want to start with.

Devildog74 wrote:

Otis wrote:

You should peek into the CliGenerator sourcecode how a set of tasks is started. If you copy that routine to your plug-in, you should be able to generate code from a plugin indeed. You can't call into the start routine inside the designer. But that's not a big problem, as the vast majority of the code is in the Generator object.

The plugin gets the ApplicationConfiguration object with the driver configs and all paths, it just has to load the generator config and the template set and that's about it.

I was wondering if you could point me in the right direction as to where to find this source code and what method I might want to start with.

The cligenerator sourcecode is available in the extras section: command line generator sourcecode. Check out the 'engine' class. it's pretty straightforward code with a couple of methods called in a chain which gather info and then call into the generator object to start the tasks.

I sent you the source code to support at llblgen pro for the first plugin. Did you receive this source and plugin?

I have been looking at the ProjectElementGroups and ProjectElemenetGroup classes in the SDK Reference Manual.

In a plugin, I understand that I can group a set of entities into a project element group, then run the plugin. I need to pull the value of the ProjectElementGroup name and pass it to an LPT so that I can use the Group Name as part of the class name in the lpt. The ultimate goal of the lpt template is to create methods and properties for all entities in the currently selected project element group.

When I inspect the ProjectElementGroups hashtable, I see entries for all of the groups that have been saved, but how can I tell which one is the "Active" one?

Devildog74 wrote:

I sent you the source code to support at llblgen pro for the first plugin. Did you receive this source and plugin?

Yes I did, thanks for that!

I haven't had time to look at it, I'll do that on monday morning and if everything is ok, I'll post it on the website

Devildog74 wrote:

I have been looking at the ProjectElementGroups and ProjectElemenetGroup classes in the SDK Reference Manual.

In a plugin, I understand that I can group a set of entities into a project element group, then run the plugin. I need to pull the value of the ProjectElementGroup name and pass it to an LPT so that I can use the Group Name as part of the class name in the lpt. The ultimate goal of the lpt template is to create methods and properties for all entities in the currently selected project element group.

When I inspect the ProjectElementGroups hashtable, I see entries for all of the groups that have been saved, but how can I tell which one is the "Active" one?

That's not available.

Though you should set the executingGenerator object's Entities, TypedLists etc. properties to teh plugin's Entities, TypedLists etc. values

I would like to be able to tell when a plugin has completed the execution process. Should I just do this at the end of the execute method?

Also, I would like to be able to tell when a plugin is closing so that I can write the last set of used values in my plugin to an xml file. Is there a particular method that I could use, similar to the "Closing" method of a windows form?

Thanks.

[Edit] One other question that I have is when does the tag member of a project item (i.e. entity, typed list, etc.) get cleared out?

[quotenick="Devildog74"]I would like to be able to tell when a plugin has completed the execution process. Should I just do this at the end of the execute method? [quote] That's indeed the end of the execution.

Also, I would like to be able to tell when a plugin is closing so that I can write the last set of used values in my plugin to an xml file. Is there a particular method that I could use, similar to the "Closing" method of a windows form?

No, though that's also to be done at the end of the execute method. When execute ends, the plugin's life is over.

[Edit] One other question that I have is when does the tag member of a project item (i.e. entity, typed list, etc.) get cleared out?

It's not cleared by my code, though they're also not saved. So when a project is saved and then re-loaded, all tags are null.

Otis wrote:

It's not cleared by my code, though they're also not saved. So when a project is saved and then re-loaded, all tags are null.

So does this mean that if I execute a plugin multiple times, there could be dirty tag objects from previous plugin execution attempts?

The reason that I ask this is because ifmy ltp is looking for "Foo" objects in the tag, and on the first execution entities 1,2,3 are selected and the generator is run, then the plugin is run again, but on the second pass we put "Foo" objects into entities 4,5,6 I dont want to generate code for entities 1,2,3 because that was generated in the first run. Does this make sense?

Yes, that's indeed the case. I don't do anything with the tag properties, so if you need a clean slate, first clear them all before you run the actual routine.