Hey guys:
In our usage of CodeSmith to generate CSLA we have found a few things to be of great use in our templates.
1) Added a property to the root templates called MyConnectionString. If this property has a value then the templates output that instead of the default connection string value.
2) Added properties to provide custom stored proc names. Often it is the case that genMyObjectName_Select is not viable, say, if your DBA says you have to use a proc called spFetchSomeOtherIrrelevantObjectInstead. So i've added properties MyDeleteCommand, MyFetchCommand, MyInsertCommand, MyUpdateCommand to the EditableRoot object and MyFetchCommand to the ReadOnlyRoot object.
3) For the NameValueList I've added properties called MyKeyField, MyKeyFieldType, MyValueField and MyValueFieldType. This way I don't require a stored proc that returns ID and Name columns of int and string respectively. I can now return int, int or string, int, etc. and the columns can be named anything I need them to be.
4) I've added a property to all templates called AdditionalUsingStatements because sometimes you have an object that needs extra using statement that you usually have to add to the editable file.
All of these dramatically cut down on the amount of code we have to write in our editable files.
Something I'm considering doing now is adding additional functionality for lazy loaded objects. We currently have ChildCollectionNames and ChildPropertyNames. By default these are loaded with the parent. Almost 100% of the time I overridt the FetchChildren function to do nothing and write lazy load properties for my child objects. I think I can add an additional set of template properties to indicate which child object I want to lazy load maybe with three new template fields.
MyLazyLoadedChildCollectionNames, MyLazyLoadedChildPropertyNames and MyLazyFetchProcedure.
With this the template can automatically emit the code necessary to lazy load all appropriate objects (after that the child objects behave as normally). The update method can be extended to not attempt to update a child object if it's null.
Now for the question. I would like to upgrade to the new 3.6 version templates and I'll have to once again carry over these changes. Are these things you guys might like in the Contrib project? If so I can send of the necessary steps for these additions. I guess this would apply mostly to Ricky Supit as he seems to be the primary contributor to the templates.
Thanks,
Will.
P.S. Rocky, see you at TechEd in May!
Those all sound like useful additions.
I did the exact same thing for NVLs a while ago.
I have my own set of templates which are unique to my coding environment so I have not been involved in these generally available templates. Thanks to Ricky (and guys like you) for keeping them up to date.
Joe
Something I was working on yesterday was editing the templates to allow for nullable types. Then I got to searching the forumns and am wondering if I am doing a bad thing? Seems like there are some issues nullable types and validation. However, as far as the templates are concerned I'm no longer setting StringRequired validation for nullable (!IsRequired) properties. Does anyone know of potential pitfalls I might run into? So far the code seems to work fine.
Thanks
Will
So, assuming these are desired features, who would I see about getting them included in the latest templates? I've also finished up the work with nullable types though it hasn't gone through much testing yet. The emitted code looks good though.
Thanks,
Will
I assume you should talk to Ricky Supit. He may have a project somewhere. Or else you send stuff to him and he edits it.
Joe
Copyright (c) Marimer LLC