Tips & Tricks: keeping elements of two projects aligned

by Giuseppe Lanzi on 01/16/2015

Today I’d like to talk about a functionality in Team Works, the Instant Developer versioning system, that not everyone knows about: the Team Works Components.

You might immediately think of Instant Developer components introduced in version 9.0, but when we talk about Team Works we’re referring to a much earlier feature. Inside an InDe project, you have the option to use the project’s  Add component context menu, which creates an object that is very similar to an application, but which functions (and is compiled) like a .dll or .jar library. These components can be exported and imported into other projects, with and without sources, so basically they respond to the need to make application functionalities modular. Each time a component is exported, the resulting .idz file contains all the elements required to use the component.

It’s a way to create and reuse complex libraries, broadly speaking. But this doesn’t always satisfy the need to align parts of the project, such as the database for example, typical of people developing a suite of products.

Let’s suppose that we have 3 work groups developing 3 different applications that use the same database, and let’s also suppose that this database is not definitive, but rather is under constant development, and perhaps is being developed using a tool outside InDe as well as being used by a third-party software. How can we distribute the definition of the database to all projects? InDe components are not the right answer, because during the export InDe puts into the component “only” everything that’s needed for the code for the component itself, which means that if all the database tables aren’t used, something will always be missing.

In the case in question, the right approach is to use a Team Works Component.

Starting with project A, you can use the  Add component command from the context menu of an object, let’s say the database, to make it public in the work group and then create the corresponding TW Component. At this point if you subscribe another project, B, to the component from A, that part will be copied in B.

Let’s suppose that the structure of the database is managed in project A. Right after check-in, all the projects that subscribe to the component will be aligned with the new version, and all the developers will receive it the next time they retrieve the latest changes. All this can be done automatically or not, depending on the configuration.

In recent months, use of this functionality has provided an excellent solution to a couple of otherwise difficult situations that are troublesome for the operators.

To learn more, you’ll find everything you need in section 14.8 of the User’s Guide.

You’ll be thinking of the ambiguity of the command’s name as well, and we agree: we could have made a better choice.

Leave a Comment

Previous post:

Next post: