We're working on some internal R&D, developing new tools, conventions, "widgets" and template files to use in our custom development.
One of the many things we're taking a closer look at is the "Selector Connector" (which I'll hereafter call "S/C" because I'm a lazy typist).
At first blush, this didn't seem like something we'd find useful. The main use case that gets demonstrated is the ability to select records from another table (usually contacts, in the demo) using a popover. We actually have a routine we call "xLink" that handles adding records on the fly, letting the user select from multiple matches, and the option to select from a list where they can do robust finds, all in another window. Works great and doesn't require context, just script parameters. So at first, we though S/C just solved a problem we didn't have.
We're giving this another look, though, for other potential uses. For example, we have several tables that can be linked to multiple basic or custom elements, including Attachments (files), Activities and Objectives (and a few more). We end up adding portals, with all their inherent TO's and filters tools and so forth, to many of our layouts and TOGs. We also have a record image widget to show an image for the record (i.e. a person or product photo), with drag and drop uploading, default image if none has been uploaded, etc. Finally, we have a navigation button bar we're currently improving, and it'd be great to be able to use virtual lists on the various popover buttons to create dynamic onscreen "menus", but without adding a bunch of TO's to every TOG.
Unfortunately, I'm getting stuck and too much of what I can find when researching S/C is really wrapped up in the one selector tool use case, and it's the one use case I don't really see myself needing.
I get the feeling that a lot of other developers have gotten way out ahead of us with implementing S/C, and I'm hoping someone has already figured out a few things that we're not getting our minds around yet. I appreciate any input you can provide, since it'll undoubtedly save us a lot of R&D and a lot of trial and error. More importantly, it could keep us from making some bad assumptions that we get away with until we're deep into a large custom solution and realize we have to restructure.
I realize this is really (at least) four separate questions, and I considered starting different threads, but I suspect that some of the explanations may overlap.
Please forgive the naive questions that are undoubtedly included. In spite of how it may appear, I'm really not a newbie; I have over 20 years under my belt and I'm certified through FM 14. Still, for some reason thinking this through is really getting the best of me. I'm really excited by the potential, but I'm also pretty nervous about making a misstep that I may not notice until it's too late to change direction gracefully.
1. Multiple Windows
This is really the main question, and questions 2-4 are more related to questions encountered while trying to address this one.
From the blogs and videos I've looked at, I've heard it mentioned in passing that multiple windows are a challenge for S/C implementation, and after messing with this for a while, it's easy to see why. If I set a key or keys in the table of globals, they're the same file-wide, even if I have three different windows open. Has anyone made any progress working this out?
We've tried creating a "session windows" table (one session record -< many session windows records), and calculating a window number from the window name. I can get the window number set or calculated (well, sorta; see question 4 below), but even when the window number is correct, the relationship sometimes doesn't update even with a commit, refresh and flush. Also, sometimes, at times I find hard to predict, an out-of-focus window will suddenly decide to update with the focus window's related records. Hoping someone has a stable solution for this. I'd settle for some new ideas to try.
2. globals table?
One of the key points about the table with only globals is that you can't lock records in that table. I can see why that's desirable, of course. Like many other developers, though, we also have a table of Sessions, unique to the current user's current session. If all the anchors were linked to the current session record, there wouldn't be record locking issues there, either, or at least not locking issues with other users.
I gather that there are other reasons to use a table with only globals. From my own cursory experience (not meticulously benchmarked as of yet) it seems that, especially on iOS, hitting the anchor of an isolated TOG is much quicker than hitting an anchor that's linked to many other TOGs. It seemed (when I saw this) as though iOS pulled down metadata about all the potentially related TO's, even if there were no related records by those relationships. Can anyone confirm or deny this? If this is true, how does a table with just globals mitigate this issue? (Or am I totally off-base and this has nothing to do with it?)
Are there other reasons this role has to be served by a globals-only table?
3. selector AND connector?
Even after a few videos and a lot of reading, I still can't quite grasp why these are separate tables. Can anyone explain it to me? One developer I discussed this with implied it was just for neatness, or just so that I could pick off the second table and all it's dependent buoys and move it somewhere else if I ever had to. I suspect that while that may be part of it, I'm still missing something here.
4. global calculations?
Presuming I do need a table with only globals, I may need to finally figure out how to use a globally stored calculation. I have to admit it's a hole in my understanding. I've just never found a good use for that, and when I've experimented I get results that seem bizarre to me. I would think that a global calc would update like an unstored calc, but instead I can't seem to get them to update reliably at all. How do I get a global calc to "fire"? I can't seem to find what I'm missing.
Thanks in advance for any help you can offer.