Freigeben über

DSL Tools Deployment - Domain-specific WiX or a DSL?

  • Artikel

None other than Rob Mensching himself, the godfather of WiX, is kind enough to mention our new deployment feature on his blog. (And rest assured, we've already fixed our slightly embarrassing file extension typo bug :-) ).

 

As Rob says,

"The DSL Setup Project is a specialized setup package builder."

i.e. it is a domain-specific setup builder (in the domain of creating DSL designers). Of course, as soon as we sniff this pattern in our code we do our darndest to dogfood. Consequently, the language used to specify the setup isn't just a plain ol' schematized xml file, rather it is a DSL tools language itself, albeit one without a graphical editor.  In actual fact we generate the XSD directly from the domain model definition.

 

You might be thinking that if the DSL tools make it so gosh-darned easy to create a graphical designer for any-old DSL, why didn't we do it in this case? Well it's a case of trying hard not to treat everything as a nail, given we have a hammer.

 

We get huge value out of going beyond schematized xml with this file; we can use our validation framework to do really rich validations of the file, far beyond what's possible with XSD and we can process the file in our text templates using a nice friendly .Net object model rather than a using a nasty DOM or other non-domain-specific API. So it's a no-brainer to use a DSL model.

 

However, it's not so obvious that a graphical language would be a great experience for processing this model. As models go, it's long on detail and lists and short on relationships (in fact it has no relationships). This screams "Forms-based UI" at me; some classes of model data are simply best expressed using traditional GUI elements rather than diagrams.

 

As the model is small, and the XML editor in Visual Studio 2005 is so good, we think the xml experience for editing this particular model stands up right now (unlike our designer definition file which we've heard loud and clear from you needs an editor).

 

Maybe we'll create a WinForms-based editor for this model (we haven't built bits to generate those automatically for a DSL just yet) or provide an InfoPath form for editing it. 

 

What do folks think about the experience of launching InfoPath from Visual Studio? Does everyone even have Office 2003 on their Dev boxes?

Comments

  • Anonymous
    December 06, 2005
    Gareth, what does the "this model" refer to when you say: "However, it's not so obvious that a graphical language would be a great experience for processing this model."

    I'm wondering if you're talking about a general UI for the WiX toolset (which would be very interesting). I've seen people try to use InfoPath on the WiX language but the generated forms always seemed quite cumbersome to use.

  • Anonymous
    December 06, 2005
    The comment has been removed

  • Anonymous
    December 06, 2005
    I am very interested in the Infopath-as-an-editor idea, beyond the scope of the setup tool. I haven't looked at DSL tools for a while, mainly due to the so called CTP madness. Since that is over, I'll give it a try again. Here are some questions I have right now:

    Creation of XSD from domain model - is this automatically supported for any domain model I create?

    Once I have an XSD, it should be fairly easy to point Infopath to that and create a form, right?

    Also, for the future: Infopath 12 will have the ability to host forms as ActiveX or WinForms controls. It seems that this would allow one to build a new type of editor for a domain model with Infopath that runs inside VS. Is this something you guys are looking at for a V2?

  • Anonymous
    December 07, 2005
    RE XSD from domain model.

    There's an intermim solution in today's bits. We'll replace this with something better in an upcoming CTP, but for now, on the DmdFileLoader class, you can call

    public static string GenerateXsdSchema(CdlModel model, string namespacePrefix, string namespaceName);

    from any text template to create a schema for your domain model.

    I didn't know that about InfoPath 12 - that sounds very interesting.

    You can alos create a simplistic file reader for many domain models (doesn't quite work with all) using the public static string GenerateModelReader(CdlModel model);
    method on the same class. This will read a model file conforming to the generated schema. All this will of course change, but it makes for quicker experiments at present.

  • Anonymous
    December 07, 2005
    I think this might turn into a slightly longer discussion. So I moved it over to the forums at

    http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=160167&SiteID=1

    Would be great if you could continue there!

  • Anonymous
    May 28, 2009
    PingBack from http://paidsurveyshub.info/story.php?title=profoundly-esoteric-image-dsl-tools-deployment-domain-specific

  • Anonymous
    June 13, 2009
    PingBack from http://quickdietsite.info/story.php?id=2914

  • Anonymous
    June 18, 2009
    PingBack from http://thestoragebench.info/story.php?id=1652