This project has moved. For the latest updates, please go here.

Sharing items between diagrams

Mar 21, 2013 at 11:15 AM
First I would like to send a big Thank You for everyone participating in this great tool, because it makes creating configurations a joy. The question I face now is that is it possible to share items (sections, elements, etc.) between diagrams? I think the answer is no, because the code for the diagrams is always re-generated.
I think it would be a nice feature to allow elements and collections be shared among diagrams, because now if I need to have some elements be shared among diagrams (have the same name), it is possible to copy-paste them, but they result in identical generated classes thus collide with each other (not if I put them into different namespaces or rename them). If this tool would allow referring to content in other diagrams, this issue would not arise.
May 2, 2014 at 7:48 PM
I second this request (and big thank you). We want to partition the elements into separate diagrams (the diagram is becoming too big to manage) without having to create a separate C# project for each type that would be shared.
Coordinator
Sep 12, 2014 at 9:35 PM
A feature like this would be quite useful. We will look into it, though it will not be a simple fix.
Coordinator
Sep 16, 2014 at 2:52 PM
Edited Sep 16, 2014 at 2:52 PM
I looked at this a bit further.

Schema Problem: Currently, a schema is generated for each csd file, so how do we present the shared element?
The most likely solution, in my opinion, is to create a copy of the shared element in each schema file during file generation. This could cause consistency issues if one csd is changed and re-generated but another is not. However, I think the benefit would far out-weigh the extra caution that will be required for the developer. A warning could also be added.


For UI, I have a few ideas:
  • Easiest, but least friendly: Give developer ability to specify shared elements in the "Configuration Section Explorer", similar to how custom types and validators are added. These shared components would then be available in the "Type" property of the elements. A visual cue should be added to the UI indicate a shared element has been selected.
  • Most user friendly, but more development: Add a new property to the "Element" that allows user to select a shared type. The tool would load all types inheriting "ConfigurationElement" in all loaded dlls, and show those in the dropdown. We might want to add a "IsShared" property to elements to keep this list smaller, or add a custom UI for this selection. Once the shared section is chosen, it will appear in the designer with a style that indicates it's external. This shape will be connected to the section. This would probably best resemble a UML class diagram design.
Please feel free to comment.
Coordinator
Sep 16, 2014 at 9:45 PM
Edited Sep 16, 2014 at 9:54 PM
I think this feature "can" be achieved although the effort it requires could be quite high.
I will try to explain my first thoughts on how we can achieve this, there are of course different possible ways of achieve this (note I don't discuss UI related stuff, only code gen phase is analyzed here)

Higher level

  1. We need to be able to reference diagrams (we should disallow circular references)
  2. We need to load all types from shared diagram referenced (directly or indirectly) by the actual diagram and import those types in generated code

Lower level

  1. Add the ability to reference another diagram should be pretty easy we only need to add a property (or bunch of properties to the csd model) to actually store the path to the referenced diagrams (note we should carefully handle file moved or deleted scenario) and build a open file dialog
  2. Load all types needed by the code generation phase from the referenced diagrams should be pretty easy as well since we load the whole referenced model and import all used types (e.g. using importedType.Namespace;)
  3. Finally the hard part :) we should avoid to serialize imported types from referenced diagrams, so we should write a custom serializer/deserializer and I really don't know how simple it is.
P.S. this can led to a dedicated Design notes 2 post :)
Coordinator
Sep 16, 2014 at 11:02 PM
You bring up some good points Max. This would definitely make a good chapter for the design doc.

I missed your 2nd point 2nd in my first analysis. Being able to reference a diagram with the shared item would be necessary to support creating the copy in the schema file. As this area is not where I am most knowledgeable, I originally thought this would be the hardest part.

I created an example set of .cs files which represent the OUTPUT that we are trying to achieve. My first impression is that it won't be too difficult to implement a custom serializer, but I could be wrong. Lately, I have been spending more time learning the serialization portion of this project.
Coordinator
Sep 17, 2014 at 5:14 PM
The explained implementation is simplistic so every diagram generates code, but there are diagrams that can reference another diagrams so in order to generate code that compile we need to import directly referenced types. My previous comment was wrong (since I start the post thinking about a slightly different and complicated approach that changed along the way) we only need to import directly referenced types (let say for example we have diagram A and diagram B, diagram A contains type T1 and diagram B contains type T2, now if we need a property of type T1 inside T2, we need to reference diagram A from diagram B and during code gen import T1 namespace).

Note that this is by no means a complete analysis, in fact I'm only thinking about code gen phase, but xsd gen should be quite easy as well.