Graph Naming Conventions

[LaRetta]

I was just bitten by my own poor logic. I wanted to see the first related Invoice for a Contact (based upon Invoices Unpaid) which would be natural creation order, so I just placed the Invoices Unpaid::Invoice directly on the layout (since I only wanted to see one). Unfortunately, it was a sorted relationship so the incorrect invoice displayed. Yes. I should have opened my graph and checked it but, as with field definitions and indicating data-type (and whether calc) within name so fields can be easily identified on the fly, I think it would be helpful to pull that concept into the graph as well.

I am considering including the relationship sort within the table occurrence name (and even whether Allow Create and/or Allow Delete) is specified. Do others take these factors into account? I've been chewing on how to include this information in my naming conventions. Ideas?

LaRetta

[Fenton]

Yes, I often add "_desc" to the end of relationships that are sorted descending. It could be a problem if you have script that goes to related records if you don't remember. Also, it tells you what you'd get with the Last() function. And whether you need to sort a portal or not.

I'll also sometimes add "_cr" for those allowing creation. But not if there's only 1 relevant relationship, and a portal's using it. In other words if most of the relationships in a simple solution have this turned on I may not bother. But in a complex solution, one that has similar relationships that do not allow creation, then it helps to know which is which.

I sometimes use "_del" at the end. It should only be on 1 relevant relationship between 2 tables. Probably a good idea to label it also.

BTW, I recently ran across a great tip for the Relationship Graph. Which is that you can create a Note on the graph, and it automatically goes behind all the TOs. So you can make it big, behind an entire TOG. Then give it a recognizable color (pastel, it has to be much lighter than your TO colors). Type the name of the TOG as the note, really BIG, like 24 or 36. The technique is that you can zoom way out in a big RG and still read the TOG names. And it's cute -).

It also makes it easier to drag a TOG around. You can select the whole TOG, while zoomed out, and drag it by holding on the background note. If you try that by clicking on a TO, it sometimes doesn't work so well. Sometimes I wish we could "Group" a TOG.

Since typing part of a TO name scrolls to the 1s instance, you may want to put a space in front of these note titles. For really BIG RG's you can also create a table of contents at the top, a bunch of little notes showing the colors. Same thing applies to the names (space or ` in front), to stop scrolling.

Some people (Matt Petrowsky at http://www.filemakermagazine.com, new free article about this) use real TO's for the TOC, so he can highlight TOs of that table. But I don't know. I kind of like just the notes, as I can type to scroll to the main TOG of a table. I suppose each method has its uses.

Of course you have to prefix your TOGs for this scrolling to work.

Edited March 5, 2006 by Guest
forgot the //

[LaRetta]

Fenton, thank you so much! I have some name changing to do on my (way-too-many) LineItems TOGs...

It could be a problem if you have script that goes to related records if you don't remember.

Ooooops.

This hasn't bitten me yet but it could have! So GTRR displays the related records in the 'relationship' sort state? I've never checked that!

LaRetta

[Fenton]

Multiple LineItems TOGs. Yes, that's pretty complex all right. Another thing that Matt Petrowsky did was to use 2 notes behind each TOG. The top one was colored, with the BIG TOG name. Then he used another, light gray, behind that TOs. He could then write regular-size text into the gray one, to explain more about the TOG. Documentation right on the RG.

(P.S. I fixed the URL to his site with the movie)