Google is your best friend

I’m still busy adapting the commands that apply changes to the model (remember :  the model is the object graph behind a diagram).  A couple of days ago, I started reworking the ‘create connector command‘; this is the command that gets executed when you use the ‘Connector tool‘ to add connectors to a line that represents a set (and that does not yet contain connectors).

It appeared that the way in which the connectors are added to the diagram isn’t that nice in some situations.  For instance, take the OFFICE-EMPLOYEE set in the EMPSCHM demo schema :  when we use the Connector tool and click in the middle of the first line fragment (the one that starts on the OFFICE record and goes down to the first bendpoint) :

connectors1

Besides the fact that both connectors are put to the right of where I clicked the mousebutton (which is acceptable), all the line fragments seem to go crazy… the diagram editor just inserts the connectors after the last bendpoint (in a straight line situation, we wouldn’t have this problem).

What would be nicer is the diagram editor inserting the connectors before the first bendpoint, like this :

connectors2

Because the connectors are now inserted before the first bendpoint, the flow of each line fragment is retained.  Moreover, the connectors are inserted one on top of the other, which is also a requirement to keep the lines flow smoothly.

So this is what I’m currently playing with 🙂

At first, I had no clue of how to figure out on which line fragment the mousebutton is clicked; it has been ages that I’ve been doing that kind of math…  Fortunately, thanks to Google (and StackOverflow) this seemed easy enough :  the first thing you have to do is to ‘imagine’ a triangle ABC for each line fragment, with the following points :

  • A :  the point at which the line fragment starts (this is a point somewhere on a record or index, or a bendpoint)
  • B :  the point at which the line fragment ends (this is a point somewhere on a record, or a bendpoint)
  • C :  the point at which the mouse button was clicked.

The next thing you do is calculate the surface (area) for each of these triangles (1 triangle per line fragment, in our example that’s 3 calculations) :

[ Ax * (By – Cy) + Bx * (Cy – Ay) + Cx * (Ay – By) ] / 2

When the surface (area) equals to zero, that line fragment contains the point at which the mousebutton was clicked.  Bendpoints are tricky because the points at which they occur always belong to 2 line fragments.  The Eclipse Graphical Editing Framework (GEF) also takes a margin of 2 pixels into account because it can be difficult to point at an exact point in the diagram.  So… the smallest surface is the winner here; that’s how the diagram editor detects the line fragment on which it has to put the connectors.

The diagram editor now also takes the direction of the target line fragment into account to decide whether the connectors should go side by side or one on top of the other.

The next version of the diagram editor will include all of these improvements.

There are other areas in which the diagram editor can be improved for what is line handling is concerned; please let me know what bothers you the most !

Merry Christmas 🙂

Advertisements

Looking forward to CA IDMS 18.5’s SQL Web Connect feature

Next year, we will be performing an upgrade to CA IDMS release 18.5 for Vivium, the insurance company I work for.  THE thing I’m looking forward to is to finally have JDBC capabilities available for our IDMS environment – we never had a license for the SQL Option and IDMS Server…  It is a bit late maybe, especially since alternatives for the relational model are emerging in the form of NoSQL databases, but nevertheless I intend to make use of this feature to offer an alternative to importing and updating schemas from their syntax

Adding new import/update capabilities to the Eclipse CA IDMS™/DB Schema Diagram Editor is fairly straightforward :  its main plug-in (‘org.lh.dmlj.schema.editor’) defines an extension point called ‘import’ for this purpose.  When you write an Eclipse plug-in, you usually extend Eclipse by defining 1 or more extensions; defining an extension point in your plug-in allows others to extend your plug-in (by defining extensions for that extension point).  The ‘import’ extension point allows you to define 1 or more import tools – import tools provide the diagram editor with the data it needs to create (or update) a schema diagram.

When you install the diagram editor, you have 1 import tool available out of the box :  ‘org.lh.dmlj.schema.editor.importTool1’ (‘Import or update a CA IDMS/DB schema from a file that contains CA IDMS/DB schema syntax.’).  When you launch the CA IDMS/DB Schema Import Wizard, you don’t need to select an import tool (in fact you can’t), since there is only one available.  When additional import tools are defined, you will have to select one though :

Import Tool Selection

After selecting an import tool, pressing the Select button will lock it; this is necessary because each import tool defines its own set of wizard pages and it’s easier to implement a wizard if you don’t need to remove and add pages (the wizard page flow can become complicated); you can always cancel and restart the wizard if you want to use a different import tool.

Besides the standard import tool, the above example lists an import tool I wrote about 2 years ago and that allows me to import or update a CA IDMS/DB schema directly from a DDLDML area whose (single) file is available on the file system; this import tool is built on my own navigational API library for Java and in which IDMS is not involved (you could say that I built a small part of the IDMS DBMS in Java).

The illustration below gives an impression of the extension point definitions for both import tools (the standard import tool is on the left) :

Image4

I will not be going into too much details here but the things to note are :

  • Each import tool has to provide a Java class that implements the ISchemaImportTool interface; it is this class that will supply all data regarding the schema.
  • There is 1 options page, which is preceded by at least 1 data entry page and followed by zero or more data entry pages.
  • You’ll need at least 1 data entry page to allow the user to select the schema to be imported or updated (hence the ‘at least 1 data entry page’ to preceed the options page)
  • The options page allows you to fine-tune the import/update operation (e.g. for IDMSNTWK)
  • Besides defining import tools, you can define your own layout managers; layout mangers determine the initial placement of records in the diagram (not applicable for update operations).

Now, back to the SQL Web Connect feature…

The idea is to define a new import tool, provide it with at least 1 data entry page that allow(s) you to select an IDMS environment, dictionary and schema, and have the associated class access the dictionary via JDBC calls.  I will most probably add a preference page as well, which will allow you to define IDMS environments and dictionaries.

The good news is that it will make the diagram editor interact directly with IDMS for the first time; the bad news is that you’ll have to wait until next year (and of course you should have either the CA IDMS SQL Option and CA IDMS Server or the SQL Web Connect feature available), but now that you have a little background on defining import tools, you can always write this (or any other) import tool yourself 🙂

To be continued…

Creating and deleting indexes

The next version of the diagram editor will allow you to create indexes and remove existing ones.  This is the first step towards making it possible to build IDMS diagrams from scratch. Of course you will want to create records and sets as well, but creating an index is relatively simple, so that’s why I’m beginning with that one 😉

The diagram editor’s palette will feature an ‘Index tool’, that, when selected (1), allows you to ‘drop’ a new index on a record, just by clicking inside a record (2).  This is illustrated with the following screenshot :

diagram1

The new index will appear in the diagram after the operation is complete…

diagram2The index will have a generated name (‘NEW-INDEX-1’ in the example above), and it will be put in a separate (new) area, whose name is directly related to the name of the index. Moreover, the index will have the following initial characteristics :

  • The INDEX POINTER will be OMITTED.
  • The set membership option is set to MANDATORY AUTOMATIC.
  • The set order is LAST.

It’s easy to add the index pointer, change the membership option (you’ll need to add the index pointer first), move the index to another area or change the name of the generated area, all using the Properties view.

Work has to be done to the diagram editor for what changing the set order is concerned, so at the time of writing this article, that is NOT yet possible; the ‘Order’ property is currently read-only :

properties1

Implementing the ‘Index tool’ revealed a weak spot in the diagram editor for what reacting to ‘model changes‘ is concerned (the model is the object graph behind a diagram). Especially the recently added Outline view expects the model to be in a consistent state when adding or removing a diagram item.  As a consequence, I’m redesigning the way the diagram editor deals with model changes :  in stead of reacting to (listening for) individual property change events, model changes are bundled (compare this to a unit of work) and the diagram editor’s components (the diagram itself, the Properties view and the Outline view) will be notified of these model changes in a more controlled way (i.e. the model will always be consistent when a component receives a notification).  More on this in a later post…

That takes a lot of work, especially since I’m also adding unit tests for all the commands that carry out the model changes (those unit tests should have been there in the first place, I know).

by Luc Hermans