justnbusiness

Friday, January 05, 2007

Changes to the templating system

So I've been struggling to find the best way to work out the template system and even though I'm not 100% certain that I found the best way to do it I think it is pretty good right now and I actually feel satisfied with it. Though I would like to come up with some ways to have a "control" like system for templates (reusable parts of templates) I'm just not sure how to do this yet so I'm still happy with 1 big template. So I made some fundamental syntax changes with the language and I sorta like it.

Previously you would have to specify which templates you wanted to use at compile time, then it would take all of your Entities and put them into each template. I toyed with having different template types such as a Family template and an Entity template where it would put each family or each entity into the template but I just never liked that much. Not only was it not elegant enough but it also ended up being a bit confusing and didn't solve any issues of strong coupling between templates or limitations with wanting a template to apply to only specific entities. So here is an example of the new system:


family Example
{
template Custom as Example.Templates.Custome in Example.Templates;

entity Test as Custom
{ }
}



In this example the template is explictly declared in the family,
this is one of the new changes. Additionally, the entity is assigned templates using the "as" clause. Currently it must only use templates found in the same family, though it might make sense to allow you to specify the fullname of the template to get to templates in other families.

So during compile time the template will be created by the Activator class and the list of all entities defined for that template are passed into it. This gives the developer the ability to specify which entities specifically get passed to the template rather than an all or none sort of deal. Additionally it gives the template developer the ability to see what templates an entity is assigned to as well as entities in relationships. So if, for example, a particular entity does not use a "list" template then your template should not create a list property for a type that will not be generated.

For example, suppose you want to create a method on your EntityBase classes GetInfoObject(), which will return a simple Info object representation of your class. Now in the old system you've just coupled your template together with an EntityInfoTemplate, which makes me ask the question why have seperate templates at all? Why not just have one template that spins through the families and generates everything just the way you want it? Well that just isn't as flexible and extensible as I would like. So in this new system you are optionally coupling yourself to the info object template because you can actually look to see if your entity calls for an InfoObject template before you create the method which would return a type that will not be generated.

Like I said, I'm not 100% certain this is the perfect way to do this but I think it brings me a little bit closer to the nebulous "control" design pattern for the template system that I cannot quite envision yet.

0 Comments:

Post a Comment

Links to this post:

Create a Link

<< Home