Udostępnij za pośrednictwem

Fundamentally open approach to Domain Specific Tooling

  • Artykuł

My last post on our deployment tools and Rob's comments on them suddenly seemed to me to be a case in miniature of our whole approach to domain specific tooling and why I'm passionate about it.

 

We take our domain-specific deployment language and convert it to WiX to get the installation job done. (WiX is itself a DSL one level lower down the abstraction stack than our language - it is converted to MSI files by the WiX toolset).

 

Two points about this are critical:

  • The templates used to do the model transformation are just text files that you can modify or add to.
  • The generated WiX files are just text files that you can modify or add to. (Of course modifying generated code is its own slippery slope)

 

As Rob points out, "if a particular developer has additional setup needs then she can take the generated .wxs file and customize/extend it."

 

This approach does mean that the MSI author is somewhat exposed to the nuts and bolts of the WiX implementation of their DSL.  It's not simply a black box tool - if the sight of an XML file makes you queasy then you'll have some acclimatizing to do.  This was what I meant by the word "open" in my title - apologies to those who have politically charged views over the use of that word ;-)

 

We don't believe that at a given point in time ANY tool addresses 100% of the needs of 100% of its customers but we don't want our customers to be blocked from having their needs met by the scope of the feature set that we happen to have implemented at that particular time.

 

In an old discussion on a feature we don't support currently Steven Kelly expressed the view that we seem to be targeting developers with our tools, whereas his esteemed tool aims more (or at least as much) to target domain experts by always doing 100% code generation thereby relieving them of the need to write any code.  A question Steven: What happens when the feature an authoring user wants isn't supported by the current version of your tooling?

 

I really believe in our approach of having both generated code and, more importantly, the mechanism by which it is generated fully malleable to developers.

 

If the success of your product or application relies on being able to implement a specific feature in your DSL designer, we shouldn’t be the ones to get in your way - or at least not more than we can possibly help.

Comments