The ORM Foundation

I've created a value constraint on an object with the following list of values (for a Status(Name) object):

{ 'Unassigned', 'Assigned', 'In Process', 'Waiting on Customer', 'Needs call Back', 'Waiting for Other Dept', 'Resolved', 'Service Not Provided', 'Not an Issue' }

This results in a long, one line list on the diagram. Does anyone know of a way to resize the diagram element? or even to make it appear, say 3 values per line?

Thanks,

Scott

I would prefer just a constraint icon and have the values accessible through a tooltip.

jMM

That's a good idea. Maybe there could be an option in the Tools > Options page with choices like: CollapseToTooltip, ExpandToList, ShowFirstFiveValues, etc.

Scott

The last discussion I had on this with Terry, we had tentatively reached the following point:

1) Use two additional properties on the ValueConstraintShape to determine layout (property names are not fixed), MaximumDisplayedValues and ValuesPerRow.
2) The default is unbounded on both values (the current behavior)

There is no natural location for a default setting (other than both unbounded) for this value. The candidates were a machine default (allowing this to affect an existing model file radically changes layout on an existing file, so this is less than ideal), model file (problems similar to global option, controlling individual diagram layout makes more sense), individual diagram (getting a good overall setting is still difficult given that value lists tend to be radically different). We could do an option for the default setting on a new constraint shape (similar to the default data type on a new value type), but would not provide a place to change all settings for the model.

We could also add a dropdown to enable editing the ranges in list form instead of delimited in a text box.

Please comment.

-Matt

At the risk of making things more confusing for the end user, what about a third property called "fudge-factor"? If I set it to "4 items per row" and I have 5 items, a fudge-factor of 1 would allow it to display that 1 extra item in the same row.

So looking at that typed out, it sounds absurd. But I'm leaving it there as "it's been considered, so anybody else with the crazy idea can see that it's been shot down".

What about a different 3rd property, "shorten to make even rows". Using the previous example, the new row would suck an extra item from the first row so that it was 3 and 2 instead of 4 and 1.

The idea behind these suggestions is that yes, value lists are radically different. Any sort of tweakable pre-set will likely have to be re-set for each list. A way for setting the layout algorithmically could alleviate this.

Come to think of it... this is an instance of the general auto-layout problem. The current layout engine seems to work fine for the diagram shapes. What about a layout engine of sorts for list items? Or an interface for list item layouts so that the layout engine could be replaced by the user? Could the diagram shape layout engine be abstracted to an interface so that it could be swapped out easily if other ones become available?

This is, of course, EXTREMELY low-priority. I like the "max items in row", "max rows displayed" property idea just fine. I'm just musing on possible extension points, and wondering if anybody else finds them useful.


Thanks for the discussion!

-- Tyler Young

It's a good suggestion to 'load balance' the rows, but I think it can be done automatically. How about the following modified proposal:
Have two properties, MaximumDisplayedValues and MaximumDisplayedColumns (instead of ValuesPerRow). This way, we are not bound by the property name to have exactly that number of columns.

Apply the following algorithm to determine the number of displayed columns:
// total is the total number of values
int values = Math.Min(this.MaximumDisplayedValues, total);
int columns = this.MaximumDisplayedColumns;
int itemsOnLastRow = values % columns;
if (itemsOnLastRow != 0)
{
    // Note that this is all integer division
    columns -= (columns - itemsOnLastRow) / ((values + columns - 1) / columns);
}

For example, this would balance (13 values, 6 maxcolumns):
abcdef
ghijkl
m

as

abcde
fghij
klm

Of course, this doesn't guarantee spatial balance because of different lengths of different values, but I think it addresses Tyler's concerns without an additional property.

-Matt

The trouble with the idea of using a column count and/or row count or max items
is that not all items are necessarily the same size. I'd rather you just have a
bounding box around the items which is displayed with draggable edges and
corners, and if not all the values fit then the last one displayed is followed by
an ellipsis. That way I can drag the dsplayed list of values into a shape that fits
around the other things on my diagram, which is the reason for wanting to limit
the displayed size anyhow.

In any case, I prefer to treat such enumerations at the ER level as a table having
a static population. That way I can enforce the value constraint with an FK, and
I can add descriptive notes for each value, a default English language string for
naming the enumeration, and perhaps a key into a localization DB for foreign
language versions of the text (I don't generally favour using the DB for localization
DBs.

I'd like to see ORM extended to allow the definition of such static populations,
togther with properties that indicate whether the population is merely initial
(open for extension by someone configuring the system during deployment, for
example), or definitive.

I realize there are enumerations needed in ORM that don't want to get the "table
treament", but I use those less often anyhow. 

Matt, Kevin, Jaron and I went over a few of the layout ideas after class tonight. Clifford, I did a mockup of your bounding box idea in HTML / javascript to see how the behavior would look. The conclusion we reached is that a bounding box would be a nice thing to have, but there are several unresolved issues. What happens when one of the values is too long to fit in the box? Do we only display part of it? What are the consequences to displaying partial data? Do we allow line breaks inside values? Only in between values?

The big sticking point of the discussion is that the VS design surface doesn't make it easy to implement a bounding box like that. In the mockup, I had Firefox's layout engine doing the display work for me. In NORMA, it'd all have to be hand-coded. It would need to be a layout engine similar in scope to a word processor. While possible, it's simply a matter of priorities with finite resources. Too many other cool things in the pipeline.

Bottom line, it will likely be implemented using Matt's algorithm that he posted above. It works well for the majority of the cases, and should be easy to implement.


-- Tyler Young

Well, that sounds fair, Tyler. I was thinking of the Visio-style bounding rectangles,
not aware something like that wouldn't be available in VS.

Wrt what to do when a value doesn't fit, drop it. If none fit, just show the { ... }.
If the list has to be truncated, the display on the diagram only really serves to
indicate that you have a value constraint there, and need to check the properties
to see the list. A {...} serves that purpose just as well as a partial list does :-).

While on this subject, how do you create a role value constraint in NORMA?

When you have a role selected, there should be a ValueRange entry listed in the Properties window, through which you can enter the value constraint.

Hi,
  Where does the idea of abstraction layering fit into this?  I'd think there are views where having the items enumerated is useful, others where just some indication that a value list exists. Looking at the boundaries in degree and scale, there will be instances where there can be no practical way to show all the items in a list on the model - and they may not conform to a series that can be abbreviated - such as {1,3,5...}.

  If you go with one of the proposals mentioned already, maybe adding a show-list/show-list-icon/hide-list property.  If you can do a visible on mouse-over to reveal a hidden list, and have use show-list-icon when printing, that might help.  Even with this, getting the list into something better than a single line will be a big help - for both on-screen and printed versions.   BRN..

Hi Scott,

  When I first saw your post, I tried the trick (see: Tip for Model Notes, in tech forum), of using CNTRL-Enter to create line breaks when entering a model note, to try to do the same for a Value Constraint list.  It didn't work, so I figured I'd wait to see what others would come up with.  With all the responses, I'm sure something workable will come out of it.  Still, could a CNTRL-Enter sequence option be added to the list property entry routine?  That way the modeler could insert the breaks as they see best works in the model they are creating - as it is with the model notes.  This might cause problems if the list populated from a source other than manual entry, but if there is an escape sequence to indicate that CNTRL-Enter is not a list item, but a formatting instruction, it could work that way too.  BRN..

A model note is stored as text in the core model (inside the orm:ORMModel element in the xml file). However, the text for a value constraint in the core model is not even stored in string form. The string you see is rebuilt on the fly when it is first requested. Any additional formatting information would need to be stored with each individual ValueConstraintShape (part of the ormDiagram:ORMDiagram element). Putting line breaks in the middle of ranges would be difficult to coordinate with changes in the core model, but line breaks between ranges (by number) could be feasible. However, I don't see how this gains that much over just setting MaxDisplayValues/MaxDisplayedColumns.

As for entering ranges (note that a discrete value is still considered to be a range), a dropdown editor in the property grid with Ctrl-Enter support between ranges would be easy to do. However, the line breaks would have semantic (core model) significance, not display significance.

Anyway, there is clearly a lot of interest in getting this right, and we'll make sure we get something discoverable and sufficiently powerful to address the ideas expressed in this thread.

-Matt