Hi,

What's the appropriate way to specify a DSL so it has some "fixed" swimlanes, just like the DSL designer has the "Classes and Relationships" and "Diagram Elements" swimlanes?

I know I could accomplish this by having the required swimlanes in the DSL item template and not providing a toolbox item for the swimlane classes, but this seems kind of hackish and the "Add After"/"Add Before"/"Delete" items in the swimlane's context menu would still be available to break the model (although a few rules could bring the model back to a healthy state).

Fernando

It has nothing to do with the toolbox item.

To have the default swimlanes created the only thing you need is to don't have a diagram map between your swimlane and any model element.

By this the swimlanes will be part of your design surface only, but not your model.

Hope this helps,

Attila

Hi Attila,

Thanks for your suggestion. Unfortunately, I don't think it will work in my case. I do want the swimlanes to be integrated with the model, instead of just being graphical decorations. I want to be able to drop certain shapes on certain swimlanes (as allowed by the embedding relationships between the domain classes represented by the swimlanes and the shapes), but I want swimlanes to be fixed (one of each kind, in fact).

Fernando

Hi Fernando,

I have some static swimlines in my DSL - I think it is working in just the way you describe.

I didn't have to do anything special to make it work like this, though. I think it must be the default behaviour for swimlanes that are mapped to domain classes.

My swimlanes are mapped to different Domain Classes, each of which is embedded in the root class. I specified the cardinality to be 1..1 in each relationship, but I'm pretty sure this is not a crucial step.

The other types of Domain Classes in my DSL are embedded in the various "swimlane" classes, as required.

I did not create any tools to correspond to the "swimlane" classes.

Now when I create a new instance of the designer, the swimlanes are always added when it first opens, and instances of their classes appear in the DSL explorer under the root.

I'm not sure where the code that does this is. If you look in the generated code, there is a method called InitializeSwimlanes in Diagram.cs, but it appears to only create them if they are not mapped, as Attila was describing.

There is also a getter in there called CreatableSwimLaneSubjects that looks like it might be used for this, but I can't see where it is called. Anyway, the main thing is that it will create the swimlanes for you automatically. Understanding how it does so is not so important, from my perspective at least.

One minor point - you can control the order of the swimlanes, but in order to do this, you have to open the DslDefinition.dsl file in the XmlEditor (right click on SolutionExplorer and select Open With.. -> XML Editor). Then you must find the SwimLaneMap tags and cut and paste them until the order in the file matches the order you want, left to right, in your designer.

Chris

Hi Chris,

Have you done anything to get rid of the delete and add actions for swimlanes in the context menus for the shapes and the nodes in the model explorer? That's what really concerns me.

Thanks,

Fernando

No - I hadn't thought of that issue, I must admit.

You can delete them at present.

I don't know if there's a way to turn this behaviour off.

If you created a tool for the swimlane class, you would be able to add a new swimlane after deleting.

Also, I notice that Ctrl-Z works OK if you delete accidentally!

I am thinking that my DSL will only be used by people who know what they are doing to a fair extent e.g. Senior developers and business analysts, so it doesn't need to be quite so bullet-proof as some more general-use software.

Chris

So for static swimlanes, the idea is to have them unmapped. We'll then generate a single one of each type defined automatically.

To make child shapes then be parented on the right swimlane you'll need to override the following method on your diagram:

///

Chris, Fernando,

I've posted some notes on how you might customise the Add / Delete behaviour of the context menus at http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=780425&SiteID=1. It's not perfect, but it's a start.

You could create rules that throw an exception if someone tries to add/ delete static swimlanes to the model (there have been other postings in the forum on this topic). This will stop the model element from being added/removed, and the user will get an error message in a message box. The downside with this approach is that you can't then load model files that have been edited manually to contain multiple swimlanes, unless you check in the rule and don't throw an exception when the model is being deserialized. This in turn creates the further problem that the user has no way of removing the offending model elements without manually editing the file, since you have remove all of the "delete" options from the designer!

Another approach is to allow the user create "invalid" models with multiple swimlanes, but warn them using validation rules.

Duncan