Home

(This documentation is pre-release)

Design Goals

(What we learned from the NuPattern project)

Don't be deeply integrated in any IDE (Design nor runtime experience)

• Being tied to a specific IDE (such as Visual Studio Ultimate 2010, 2012, 2013) limited the developer audience considerably, and resulted in a VS only toolset. (Things have changed since 2009!)
• Integrating with a specific IDE (such as Visual Studio Ultimate 2010, 2012, 2013) made the design tools constrained to what VS could do, and was seriously limiting to the contributor's ability to customize VSX (very difficult, rare knowledge set, and out of reach for most developers in the world). Also, VS releases forced us to upgrade to every VS version, when many of the extensibility points change between versions (some have been obsoleted even!)

We may choose to separate the authoring experience from the runtime experience.

• Authoring - (defining the toolkit) the identification of the patterns and creation of the templates and assets, creating the commands
• Runtime - (running the toolkit) running the commands, writing using the templates

We may choose for example to do authoring in the browser on a central SAAS site (that examines the code and teases out the patterns) and lets the author define the commands. That way everyone gets the same experience, and we stay out of the IDE's, and we will get a better UX there than in any one tool. No more managing various versions of various plugins to the various IDE's.

We may choose to use open source tools to do the [runtime] generation (i.e. automating yeoman, resharper, T4 templates etc) depending on the developer tool-chain and platform. Such as 'gulp' or 'npm' tasks, or other runners on the various platforms.

We might then store any generation artifacts and model configuration in the developers account (to be exportable when offline for running with tools).

Messaging & Positioning

"We are not a code generator, we are a code writer"

We need to be very clear with customers from the start that what they are going to get is a 'toolkit' that was derived from their code base. Not a general toolkit that someone else created for them, and in most cases not likely to be used by anyone else (although that is encouraged for solution providers who bake their IP into their toolkits to reuse across projects).

The code that will be written is code that they designed for their project - not decided by the code-generator.

We have to distance ourselves from the idea that this is another code generator technology.

Generated artifacts

In nupattern, we generated C# code (using various code-gen patterns) to separate the following kinds of code:

• Code that was controlled by the toolkit (*.gen.any) - usually using partial classes.
• Code that was created once by the toolkit, then controlled by developer. (*.any) - usually using partial classes paired with generated code

We will still need these kinds of files.

Let's call them 'twoway' and 'oneway' generation patterns.

We will then need to keep track in some manifest of what files are which, instead of polluting the source code with that info. (could also be in a single json file at root of project i.e. 'auto-mate.json')