I just added the adapter template for creating derived entities and was wondering what everyone is calling their extended classes? I'm trying to think of something different than 'My', but having some troubles..

I have just been adding Custom to the End of the orginal class name. Could be better but it works

Extended could work as well for a suffix As long as it is consistent it's ok, but consistency is the key.

Thanks everyone, I think I like 'Extended'

Ok, I changed the two templates, but my files are named 'MyClass'...

How do I change the file name so the code generator names it CustomerEntityExtended.vb?

MarcoP wrote:

Ok, I changed the two templates, but my files are named 'MyClass'...

How do I change the file name so the code generator names it CustomerEntityExtended.vb?

Alter the special derived classes generator config file to do that

I initially took the approach of generating derived entities which I named <entityName>. This seemed all good but I ended up having to change a lot of the standard templates (see the 3rd party code 'Extended entity generator templates for Adapter'). You have to change the code because all the standard templates are operating on entities named <entityName>Entity, so you have to change the factory code, override all the relations for databinding... This will work but is a pain.

Then a much simplier way occured to me.

-Add a custom template to create extended entities named <entityName>Entity (the same name as the standard entities)

-Change the standard entity template so it generates entities name <entityName>Base.

-Change the custom template from step #1 so that the class extends the class <entityName>Base.

You end up with this class structure...

// this is a custom derived entity 
// this class is generated once
public class AccountEntity : AccountEntityBase
{}

// this is the standard generated entity (just renamed)
// this class is overwritten on each generation
public class AccountEntityBase : EntityBase2
{}

This setup works pretty well; I get my custom class and dont have to change a lot of the standard templates.

-CT

Clever! Why didn't I think of that...

That small change can easily be added to the templatesets, 1 template more is not that much. I'll add it to the todo list

This was another idea that came to me in the shower, not that any of you want to hear about that.

Since we're talking about this, I'll thow out another change I made...

I changed the standard entity template so that it extends a class called BaseEntity (name doesnt really matter). This class is generated once (not overwritten) and extends BaseEntity2. I added a template to the config to generate this class for me. This allows you to put in custom handwritten code in a base classes which all derived entities will inherit. Without this class you would have to either...

-generate the functionality in the the standard entity classes (which means changing the standard entity template)

or

-generate the functionality in the extended entity classes

Either case doesnt allow you to operate on a generic base class (for utility methods) and requires you to 'code' in the template.

So my entity class heirarchy looks like this (with the above concept included)...

// this is a custom derived entity 
// this class is generated once
public class AccountEntity : AccountEntityBase
{}

// this is the standard generated entity (just renamed)
// this class is overwritten on each generation
public class AccountEntityBase : BaseEntity
{}

// this is a custom base class for all entities
// this class is generated once
public class BaseEntity : EntityBase2
{}

This is all based on my theory and experience of generated code. Generated code needs to be buffered (top and bottom) by handwritten code. If not, people will start hacking the generated code and feel that the only way to make changes is to change the generator. Code generators can save a ton of time, but can actually cause productivity and code quality issues if used incorrectly. If I could only tell you about the code generators at my current client.

I can post my templates if you like, but they are very simple.

-CT

Was there are reason you didn't opt for a template include, bound to Custom_EntityAdapterTemplate ?

Yes, for two reasons....

1) The custom code would be put at the "entity" level of the class heirarchy; you then can't build utility methods that operate on all entities because there isn't a single class that provides the "interface" you need to access. You could create a real interface and change the standard generated entities to implement that interface and then build methods that act on that interface, but now your're changing the standard template a lot.

2) Using the include template feature forces you to write your code in the template file(which is suboptimal) and then regenerate your project (which increase the developer inner-loop). I'd rather do my coding in VS.NET instead of a template file, especially since most of the code we are talking about isn't going to be entity specific, given that it's "base entity" generic.

I like the idea of template includes for custom code, it's a powerful feature that allows customization without having to change the templates. However, I dont think that entity base methods are a good use of the feature. In theory, the proper solution would be to change to EntityBase2 class, but given the situation that is even a worse solution.

Thanks CT

Sorry to barge in the discussion like this, bu can anyone explain what are "template includes". What I know upto this minute about the template system in LLBL is as follows: 1- a generator proecess relies on task perfomres and templates. 2- generator requires two config files (one for task perfromers and one for the templates) 3- we could build or customize our own templates and reference the new templates in the template set config file.

In this scheme, where does the "template includes" fall in.

I am actually facing the same situation as CT in my current project (I need some standard methods in all entities). I was thinking of modifying the template for the (extended entity generator) so that the generated classes would have these methods. I guess that CT does present a convincing argument although I always get worried when I extend the inheritence chain without a real good reason for it. I guess I have to raise this issue tomorrow with the guys at the office..

OMAR

From my understanding, and someone please correct me if I'm wrong, template includes allow you to write custom templates wich are inline included in the standard templates before code generation. This effectivly allows you to customize the standard templates without having to change the standard template file.

I try to stay away from changing the standard templates as much as possible so that when new versions are released I can take advantage of them easily, without having to rewrite them to fit my needs.

CT

WOW... that sounds great..

where can I find examples of this... does LLBL use template includes anywhere in its templares... and how to refernce "template includes" in standard templates...

lots of questions and lots of possibilities...

CT.. I think I am inclined to your approach for implementing the common service routines in a standard base class

OMAR

ctadlock wrote:

Yes, for two reasons....

1) The custom code would be put at the "entity" level of the class heirarchy; you then can't build utility methods that operate on all entities because there isn't a single class that provides the "interface" you need to access. You could create a real interface and change the standard generated entities to implement that interface and then build methods that act on that interface, but now your're changing the standard template a lot.

Ok, that's a good reason. You can also do that in the derived templates however: - define an interface - let the derived entity implement that interface in the derived entity template - add your code to the derived entity template, or even an included template in that template.

You then don't have to alter a single line in the stock templates, which is IMHO preferable (but ok, this is minor).

2) Using the include template feature forces you to write your code in the template file(which is suboptimal) and then regenerate your project (which increase the developer inner-loop). I'd rather do my coding in VS.NET instead of a template file, especially since most of the code we are talking about isn't going to be entity specific, given that it's "base entity" generic.

Understandable, and re-generating a project is perhaps not what you want indeed... 'Injecting' code through defining a base class underneath the existing classes is rather neat, it's the world upside down, but still I like it . It's also making your project less bloathed, as 1 class with code shared by all entity classes is preferable over 1 class for each entity with the same redundant code.

I like the idea of template includes for custom code, it's a powerful feature that allows customization without having to change the templates. However, I dont think that entity base methods are a good use of the feature. In theory, the proper solution would be to change to EntityBase2 class, but given the situation that is even a worse solution.

You got a point there.

omar wrote:

WOW... that sounds great..

where can I find examples of this... does LLBL use template includes anywhere in its templares... and how to refernce "template includes" in standard templates...

lots of questions and lots of possibilities...

CT.. I think I am inclined to your approach for implementing the common service routines in a standard base class OMAR

Omar, have you checked out the SDK in the Extras section in the customer area?

Standard templates have a 'Custom' include at the bottom. These includes are not used by default, so no code ends up there, but you can bind the custom template ID for a given template to your own template file in a template config and it will generate the code in your custom template file inside the area at the bottom of the standard template.

Includes are used at the moment for the DQE namespace name in the DAO templates, for the entityfactory create method body and the validator method body.