Skip to content
Jezz Santos edited this page Apr 4, 2017 · 9 revisions

(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
  • Integrating with a specific IDE (such as Visual Studio Ultimate 2010, 2012, 2013) made the design tools constrained to what VS could do, and/or the contributor's ability to customize VSX (very difficult, rare knowledge set, and out of reach for most developers in the world). Also, having to upgrade every VS version, when many of the extensibility points change between versions, and some are obsoleted even!

We may choose to separate the authoring experience form the runtime experience. 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 we may choose to use open source tools to do the runtime generation (i.e. yeoman, resharper, T4 templates etc) depending on the developer tool-chain. We can then store any generation artifacts and model configuration on the cloud (to be exported when offline).

Messaging

"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. The code that will be created is code that they created. We have to distance ourselves from the idea that this is another code generator technology.

Generated artifacts

In nupattern, we generated C# code and 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 still need these kinds of files. Let's call them duplex and oneway generation patterns. Now we will need to keep track in some manifest of what files are which.

Clone this wiki locally