Introduction
The Charta environment works on a database, Charta.data. Lots of projects have very valuable data and code within its database. Functions like querying an SQL database, drawing objects, calculating statistics, etc. Or data like country information, postal codes, etc. This data can be saved by exporting the database to an XML file.
Now you start a new project and create a new Charta.data. In this new project you want to use some functionality or data from another database. You can do this by importing the XML file of the database that contains the functionality or data. But then two problems arise:
- Overkill:
You get everything from the other database (which might be a lot more than the needed functionality/data) - Redundancy:
There might be objects in the other database that are the same as objects in your database, and they are not matched (you will get redundant objects).
How to solve the overkill
It is already possible to prevent importing too much from another database: by hand. You can make a clean version of a database that only contains the data and functionality that you need. Then you export it to an XML file, which can be imported in your own database.
This way of solving the problem is in essence what you want. But Charta should be able to do it for you. This means that the export functionality is to be extended. The following describes the new export process:
- When you click the export button you will get a view of the Charta tree containing all the objects present in the database.
- You select the objects that you want to export.
- When selecting an object it will automatically select all the (grand)child objects, which you can deselect again if you want.
- You choose a name and directory for your XML file.
- You confirm the export and the objects in your selection (including the objects they depend on) will be exported to your XML file.
How to solve the redundancy
When importing an XML file in your database, all the new objects are just added to the end of the tree. But it could be that you already have an object in your database that matches one of the new objects. And you want it to replace the newly imported object.
For example, you have a class Point and the imported objects also contain a class Point. Every time the new Point is used, you want your Point to be used instead.
It is already possible to solve this problem: by hand again. You rename the newly imported object. You lookup all the references to the object. And you replace the reference by a reference to your own object.
Instead of doing this work afterwards, you want to tell the import that two objects are the same and that the new object should be replaced by the object of your choice. Therefore, the import functionality should be extended. The following describes the new import process:
- When you click the import button, you select the XML file to import.
- You will get a view of the object tree that is to be added to your Charta tree and you will get a view of your Charta tree itself.
Underneath the two views you will get a table with two columns: one column for the import objects and one column for the original objects. - For every match you will insert a row into the table. In the first cell of the row you select the import object you want to replace. In the second cell of the row you select the original object you want to replace the import object with.
- You confirm the import.
Conclusion
In the end we would like to have one big Charta repository in which each and everyone can put its contribution to Charta. And which is version controlled so that you can always get to a good working environment. The above is a first step to this end goal.