What Does a T4/Code Generation Harness Need to do?
I'm struggling to get the AppVenture Community Edition Code Generation harness into release because I can't figure out where the boundaries should be. I initially thought I could just reuse my old stuff in the area of data extraction and mapping/morphing, but too much has changed.
- Multi-UI supporting core code generation engine
- Full composability via MEF
- Configuration driven ordering of automatically discovered templates
- Template focused generation (templates know stuff)
- Multi-file output via a simple naming mechanism
- Support for VB 9 XML literal templates
- Support for T4 templates
- A few example templates at Hello <item> level
- Key service interfaces defined
- T4 property extraction/value setting
- Partial data extraction (tables and a few others)
- Rudimentary US English pluralization service
- Full data extraction (views, foreign keys, etc)
- Mapping across data/object impedance mismatch boundary
- Full project templates (stored procs and biz layer)
- Hashing output files to protect handcrafted code
- Services to load stored procedures
- Services to create project files
- XSLT template support
- More services such as a better naming service
The core of this design is that I do not want to stand between you and your templates, metadata or services. Thus if you have metadata, you can hook this up and generate anything you can write T4 or VB9 XML literal templates for. You can create any services, metadata or templates you want.
Delaying stuff is hard. I want this to fully meet the capabilities of the GenDotNet harness so I can retire it. This is a vastly superior way to approach the problem.
So, where's the boundary? For this tool to be worth a look, what does it need to do? This is V1, the rest will come. I'm trying to balance when to release V1 and I'm doing this all in my "spare" time so some patience will be needed.