Copying views

Overview

Once you have created a form or grid view you might want to re-use it in a different data tree. Starting with Instant JChem 2.5 this is possible by copying the view and pasting it into a different data tree. This is most useful for a form view, as creating a new grid view is very simple and quick.

When a view is pasted into a different data tree the widgets that were present in the original form need to be re-bound to the fields in the new data tree. IJC tries to find the best matches based on field names and types, but if the data trees are quite different in composition then this matching process may not be totally correct and some manual re-design of the form will be required. This is especially true for more complex relational data trees.

How to copy a form

These examples use data in the demo project that comes with Instant JChem. To create a new project containing this demo data use 'New project' from the 'File' menu.

Simple case - identical data trees

In this example we will copy a form from the Wombat data tree (can be found in the demo data that comes with IJC) back into the same data tree. This illustrates a situation where all of the fields will match. A more realistic scenario might be when you are migrating data from a local database to an Oracle or MySQL database.

  1. Expand the 'Wombat (compound view)' data tree in the projects window.

  2. Right click on the 'Wombat compounds' form and choose 'Copy'

  3. Right click on the 'Wombat (compound view)' data tree and choose 'Paste'. A dialog will appear that lets you match the fields.

  4. All fields will have a 100% match so you can click on the 'OK' button to accept the field mapping. The copied form will be added to the data tree.

images/download/attachments/1805247/image2019-10-24_15-22-33.png

More complex case - different data trees

In this example we will copy a form from the Pubchem to Wombat demo data. This illustrates a situation where some of the fields will match and some will not.

  1. Expand the 'Pubchem demo' data tree in the projects window.

  2. Right click on the 'Pubchem single record form' form and choose 'Copy'

  3. Right click on the 'Wombat (compound view)' data tree and choose 'Paste'. A dialog will appear that lets you match the fields.

  4. The fields differ considerably between the two data tree so differing levels of match are found.

  5. Manually redefine the binding of the field to the form widgets, and when finished click on the 'OK' button to accept the field mapping. The copied form will be added to the data tree.

images/download/attachments/1805247/image2019-10-24_15-29-3.png

About field mapping

Instant JChem attempts to determine the best match between fields used in the source and destination data tree. This mapping is done using:

  • Field name e.g. fields with the same name will be considered a good match, those with a similar name a less good match.

  • Field type e.g. if a widget is bound to an integer field in the source data tree then an integer field in the destination data tree will have a better match than a text field.
    Each field is assessed and given an overall percentage score. Perfect matches will score at 100%, less perfect ones at a lower score. The field with the highest score will be selected as the default.

The field that is bound to a particular widget can be manually changed by using the combo box in the 'Replace with' column. You can change the binding to a different field, or specify that the widget should be removed from the pasted form.

Limitations

Whilst the process is reliable for identical data trees, the automatic mapping to the fields of the new data tree gets less good the bigger the differences that exist between the source and destination data trees. This is especially the case for relational data trees where the mapping of widgets needs to consider not just the fields but also the different entities in the data tree. In these complex cases manual adjustment of the mapping will almost certainly be necessary, and some manual re-design of the pasted from will probably also be necessary.

You may encounter these limitations:

  • A field might be detected as a best match to two different widgets. You probably need to select the field for only a single widget.

  • When mapping fields in tables there is no check that the fields come from the same entity. You should not specify fields from multiple entities. If you do so all fields from the "wrong" entity will be removed when the operation completes.

Widget format on copy

All of the formatting (internal alignment, width, title and column order) for form view's bound widget are retained on copying forms and this avoids duplication of work during the form development phase - forms can be reused in other schemas.