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

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?
 
Published 06 December 05 02:27 by GarethJ
Filed under: ,

Comments

# robmen said on December 6, 2005 5:53 PM:
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.
# GarethJ said on December 6, 2005 9:26 PM:
Nope, I was refering to our Deployment DSL itself, which is generative of general purpose WiX.

WiX itself seems to have plenty of cross references in it, which is one of the signs that it would be quite amenable to a box-and line style graphical language, although it also has heavy-duty detail, so I think you'd probably be looking at a hybrid, with diagrams for the large scale structures that are represented and referenced and something more terse such as GUI for the detail. As there's a good deal of hierarchy, something structured in a tree like the DSL Tools Domain Model Designer might work out well.
# David said on December 7, 2005 6:06 AM:
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?
# GarethJ said on December 7, 2005 8:21 AM:
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.
# David said on December 7, 2005 9:46 AM:
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!
# Profoundly Esoteric Image DSL Tools Deployment Domain specific | Paid Surveys said on May 28, 2009 7:18 PM:

PingBack from http://paidsurveyshub.info/story.php?title=profoundly-esoteric-image-dsl-tools-deployment-domain-specific

# Profoundly Esoteric Image DSL Tools Deployment Domain specific | Quick Diets said on June 13, 2009 9:54 AM:

PingBack from http://quickdietsite.info/story.php?id=2914

# Profoundly Esoteric Image DSL Tools Deployment Domain specific | storage bench said on June 19, 2009 4:29 AM:

PingBack from http://thestoragebench.info/story.php?id=1652

New Comments to this post are disabled

Search

This Blog

Disclaimer
The information in this weblog is provided "AS IS" with no warranties, and confers no rights. This weblog does not represent the thoughts, intentions, plans or strategies of my employer. It is solely my opinion. Inappropriate comments will be deleted at the authors discretion.
All code samples are provided "AS IS" without warranty of any kind, either express or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

Tags

Archives

Architects who Model

DSL Tools Team

Links

Syndication

Page view tracker