The ORM Foundation

Hi,

The way I use the Fact Editor (and I almost never create Fact Types from the toolbox, unless necessary), it seems like an extra step is required for each FT I create.  Usually, I'll hit CNTRL-Enter to commit the FT, then CNTRL-A (if the new FT is the only thing in the designer page), or drag a box around the new FT, so I can move it to a better place in the desingner.  Missing an element with the boxing, means yet another few actions to correct for that.

I think it would be better if the elements of the newly created FT were left as selected in the designer.  It's easy enough to click a blank area (to de-select), or another element on the page, is that's what you want.

BRN..

Selection behavior from the FactEditor was a difficult choice, and the decision to not select was not done lightly. The issue is that the Fact Editor can also be used to edit an existing (selected) FactType, so a subsequent entry meant to add a new FactType would mean that the current one was edited instead of a new one being created. Note that there a couple of relatively new (March 08 timeframe) selection-based behaviors in the Fact Editor. In other words, entering multiple FactTypes with Ctrl-Enter would result in a single FactType on the diagram.

• Selecting one (or more, for the n-ary case) roles with Ctrl-Click gestures will pre-populate the FactEditor with the selected ObjectType names and use the selected order as the default on entry. The goal of this is to make it easy to use the FactEditor to enter alternate reading orders.
• Selecting multiple ObjectTypes will prepopulate the FactEditor. For example, holding the control key down and clicking two ObjectTypes following by WF (don't like the control key when you type) will leave you in the FactEditor window in the perfect position to enter a new FactType.

We know that the auto-layout mechanism used to layout new FactTypes is weak, we've just had higher priority issues recently. Note that placing selection in the Model Browser window will result in the creation of no new shapes. You can drag the new FactTypes from the Model Browser or Context Window unto a diagram later.

But I digress. Returning to your original point, I think it would be good to add additional keystrokes to signal completion in the FactEditor. Adding a toolbar to highlight the different available commands would also be useful (I'd like to add toolbars to the Notes and Information Definition editor windows as well to provide a commit mechanism without changing the selection). Some alternative actions for new FactTypes (not available with edits of a selected FactType):

• Add the new FactType, automatically place it on the diagram, and switch selection to the diagram (Ctrl-Shift-Enter) (More usefull if our initial placement is smarter)
• Add the new FactType to the model but do not place it in the diagram, but activate a mouse action so that it can be explicitly placed (Shift-Enter). This would be a lot like using the toolbox, but the FactType arrives on the diagram with a reading.
• Other suggestions?

-Matt

Hi Matt,

Thanks for the notes on selection behavior for Fact Editor entries.  This is an important issue, as it gets to the heart of efficient entry and editing of Fact Types.  The "weak" auto-layout is an understandable consequence of the development process (just not as high a priority as functional and stability issues).

It was the need to select the new Fact type, in order to relocate it in the designer that prompted the post - if it was an easy and uncomplicated fix; that would have been fine.  The current situation isn't intolerable, just a drag (no pun intended).

Looking at it strictly from an end user's perspective, I wonder if splitting the functionality of the Fact Editor makes sense - perhaps not into two separate windows, but a way to easily switch between two modes.  There is certainly a need to edit Fact Types; but a better way to enter a number of new Fact Types would be helpful.  I guess this would move the functionality from being a Fact Editor, towards becoming a Fact Processor.

This issue seems related to something brought up about a year ago - concerning a grammar for ORM 2, and the ability to enter a fully constrained Fact Type using just text.  Something like:

                 Employee(.id) has at most one FirstName()

Here, an IUC would be assigned to Role1 of the FT.  Where:

                 Project(.id) has exactly one CodeName()

would have each role constrained.  I don't know how difficult that would be, let alone considering disjunctive, external, subset and ring constraints.  I don't know that it has to be all or nothing, however.  I'd guess more than 80% of FTs could be entered using basic IUC on binary assignments.  Is this something you are working toward?

Perhaps you already answered this; but is there a way to have the (edited) contents of the current Fact Editor not overwrite an existing FT, but rather generate a new FT in the designer?

                 Employee(.id) has access to Building(.name) on Date()

                 Employee(.id) has access to Building(.name) for Project(.id)

To enter the second FT, it would be easier (and less error prone), to select the first (existing) FT, edit the last part, then commit that as a new, additional, FT.

As central as the Fact Editor is to the whole process, I expect we'll see a lot of posts on the topic - so I'll refrain from adding any more bifurcations to this thread.  I'll work with what you've provided already, and see where I can get with that.

I would say that your adding notes on the current functionality, as you make changes, is very important (just to let us know they are there).  That may be too much to take in with the install README.  Tagged posts in this forum would be a good way to let us know what you've done, and why the changes were made (with the added benefit of being searchable).  When you have the time, please continue to do so.

BRN..