Team Collaboration Best Practices

As one of the lead dsn architects/authors for our Altia Services team, I can concur that some production dsn files can get rather large, and it can be tricky to manage the dsn as it grows, especially if your organization has multiple people working on the same dsn/project. I have included below some of our own methods/best practices which we have used over the years. Hopefully they help you out as well.


First of all, while you might prefer to build sections of the whole model in different dsn files, keep in mind that the production dsn file will need to be a single dsn file eventually, regardless of size, since that is required to generate code from.


As of this writing, the Product team has plans for better collaboration features (but no schedules yet), such as adding n-Depth classing support, and also some additional team/collaboration features.

For now, Classing is truly only designed to work with single-level instances (so the instances should be leaf-level widgets, not parent level screens/section of a model).

As for making people work on sections of a model:

You have a main.dsn...this is where you pull in all the content from other users (if you want the main.dsn to be worked on simultaneously by multiple people).

The other content from the other dsn files can be whole screens IF and only IF (for now, without n-depth classing), you pull in those entire screens/sections into the main.dsn file as a Group, not an Instance.

NOTE: The Screen/section Group that you drag into main.dsn can CONTAIN instances, but only for widgets like buttons, sliders, line items for lists, etc. The parent group with all its nested hierarchy/content must be dragged into main.dsn as a Group/Copy, however.

If you are concerned about people editing the content of the imported sections, while that is valid, my only current suggestion would be to change each imported sections/screen's top level group name in Navigator to something like:

"===DO NOT EDIT BELOW THIS!!! MAKE CHANGES IN SOURCE DSN, THEN DELETE/RE-IMPORT THIS TOP LEVEL GROUP==="

That should stick out like sore thumb in the Navigator pane. ;)

To be clear, you do not need everything at a giant top-level flat hierarchy. You can have complex nested groups, decks within decks, etc. It's just that if you drag something in as an Instance, all of its content must be normal groups/decks/etc within itself. An Instance cannot have as part of its content be an Instance of something else. There is one exception to this rule, but it is beyond the scope of these common guidelines.

I typically make a projectname_base_classes.dsn which is an "artist palette" to grab various widgets from in order to make instance of things like list line items, buttons, sliders, etc. Those all exist as siblings at focus level 0 (top level of the base class dsn).

Finally, as a production dsn Best Practice:

Try to think of your GUI as a series of "Layouts". That is, if two "Screens" look/appear the same, then you should only build/use one set of common objects (what I call a common "Layout") for those 2 (or 200) similar screens.

For example, if you have 100 "Warning" screens that are all just 4 line messages and a possible icon, make 4 Text I/O objects and 1 Deck to handle all possible icons. It's up to logic to use that same set of objects (the same Layout) for all possible permutations of it by sending it the appropriate deck card value and proper sting info for the warning.

Another classic example of this is a common top and bottom bar. Ensure that common elements like that are outside of hierarchies that are changing a lot, so that you can re-use the same top/bottom bar objects across all the screens in your GUI.

Using common layouts greatly reduces dsn complexity, and size, making managing the dsn much easier.

Source Control

Currently, a dsn file is a binary file format, so what I typically do is check in each modified dsn file as the same name, so it gets versioned, but I include detailed commit notes. I also and add any new files to the repository, like new images (if applicable) with each check-in/push. Any CVS/DCVS tool like GitHub, Subversion, etc. will work. The C code is checked in as with any other code-based project using source control.

Using the methods above is how 99% of production dsn files are successfully built, both internally at Altia and often externally by our customers.

Have more questions? Submit a request

0 Comments

Please sign in to leave a comment.