1 2 Previous Next 17 Replies Latest reply on Oct 12, 2015 9:40 PM by Todd Geist

    Selector Connector Questions

    Extensitech

      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.

       

      Chris Cain

      Extensitech

        • 1. Re: Selector Connector Questions
          mikebeargie

          Hey Chris,

           

          I'd highly recommend watching ISOFM's video on it if you haven't already:

          https://www.youtube.com/watch?v=ml-WF7qfMB0

           

          May answer a few of your questions like #3 (see 8:40) . There doesn't HAVE to be two tables, it can be accomplished with just the "connector" table in the demo file, but the selector table adds an additional ease of connectivity for parent/child relationships. I treat the "connector" side table as the parent, and selector sides as a child.

           

          For #4 - global calculations evaluate slightly differently than calculation field types:

          A calculation Field Returns a Different Result Than Expected | FileMaker

          There's a demo file and explanation there that might help you out.

           

          In a vague comment to your #1 question (and possibly helping with your thoughts), I've personally only used this model in systems where I implement CRUD standards, pretty much in filemaker terms making a system transactional, and controlling the commit on records so that nothing auto-commits. A good example of a file that uses this technique along with Selector-Connector is FMEasySync. Although it doesn't use a separate selector table (just the connector), it does all of it's writes and updates transactionally.

           

          I've found only rare opportunities (like EasySync) to implement this method myself. It's a steeper learning curve, and since I hand off a lot of my code to other developers that I mentor, it's not exactly the easiest thing to explain. There are performance, modularity and other benefits associated with the model, but FileMaker does a bang up job for most of the actions I need without any complex technique.

          • 2. Re: Selector Connector Questions
            Extensitech

            Thanks for your input, Mike.

             

            Coincidentally, I came across the video you mention since I posted this.

             

            Thanks for the reference for global calcs. It does help me understand better. Unfortunately, I can't (yet) think of how that will help with challenge 1. Of course, I can't yet think of a scenario where a global calc would be useful at all, so maybe I just need to keep thinking.

             

            So I guess we're down to questions 1 and 2, unless anyone has more to say on 3 and 4.

             

            You did say "vague comment", but I'm having trouble connecting what you're telling me about crud and transactions to the question of how to use S/C in a solution that allows multiple windows. I'm not sure if I'm just missing the connection, or if I was unclear. In case it's the latter: our solutions usually allow for Window->New Window. It's not so much about windows for scripts and the like (we use those, too, but that seems fairly manageable), but rather use cases like someone in the middle of doing data entry gets a call and opens another window so they can record the details of the call without losing their place on the original data entry window.

             

            Chris Cain

            Extensitech

            • 3. Re: Selector Connector Questions
              mikebeargie

              Ah, to clarify that. In cases of multiple windows the idea would be that you load your "selected/connected" data in only the front active window. The basic gist of it is that since CRUD is limiting your commit actions, you only need to be able to edit/save to one table at a time. So your background windows would not have data really loaded to them while the front window is active.

               

              To get around the multiple window conundrum, I would add some creative window triggers for the window open/close and layout enter/exit to store/restore table/set/position in each window as it is focused/unfocused/opened/closed. It seems like a colossal pain to get that done file-wide though, so my preference would be to make a single-window solution (which is my usual preference anyways).

              • 4. Re: Selector Connector Questions
                Extensitech

                Oh, OK. We currently offer our users the ability to spawn a second window with a full set of tools, though. We're starting to think that this or S/C may be an either/or proposition. :-(

                 

                We could certainly make our solutions single window, but it has the feel of "dumbing down" FM's native capabilities. Being able to have multiple window instances going so you can compare side by side, work on two things at once, etc. is pretty nice. We even have independent back and forward capabilities for each window already. For us, this would be a pretty big step backwards.

                 

                Our base solution already has the necessary tools for managing record loading, etc, so the proposition isn't as daunting as it might seem in a "from scratch" solution. As I said, though, we're seeing some strange results. Even though we can correctly calculate or set a window number, we can't seem to get the relationships to resolve, and we're getting some odd refreshing in the unfocused window (and even occasionally in the focus window).

                 

                I'm really hoping someone's figured out how to make this stable across multiple windows.

                 

                Chris Cain

                Extensitech

                • 5. Re: Selector Connector Questions
                  Todd Geist

                  Hi Chris,

                   

                  I think it will be very difficult to get Selector Connector to work with multiple windows. Neither Jason Young of SeedCode or I are big fans of using multiple windows to show record details. They cause too many problems to be worth it. So we never even considered it when we were kicking around what was to become Selector Connector.

                   

                  Selector Connector solves a large range of problems, some that have to do with the problem of context, some that have to do with solution organization, some that have to with code re-use, and others that have to do with Transactions, ( ie commit and rollback ). In my opinion, these benefits far outweigh the loss of a dangerous feature like multiple windows.

                   

                  If you haven't already seen Jason's recent blog post on Selector Connector, I would recommend it.

                   

                  http://www.seedcode.com/filemaker-selector-connector-basics/

                   

                  Good luck :-)


                  Todd

                  • 6. Re: Selector Connector Questions
                    Extensitech

                    ToddGeist

                     

                    Thanks so much for weighing in, here.

                     

                    It appears that we've already solved this "large range of problems", but in different ways. No offence at all meant to the S/C way; it's super-elegant and impressive!

                     

                    The exception is the context, by which I mean the re-usability of layout objects without having to re-point everything, or add TO's. Right now we make heavy use of clip manager for that. OTOH, we're allowing our users to use the native "New Window" command without issues. (I'm surprised to hear multiple windows called "dangerous", frankly, but that's possibly another thread or a back-channel conversation?)

                     

                    We're already weighing pros and cons in case this turns out, in the end, to be a strictly either/or proposition between S/C and allowing multiple windows. The jury's still out at the moment, but right now we know more about the benefits of multiple windows to a user than about the ease of development with S/C, so we still have some research to do before we can make an intelligent choice.

                     

                    I'd still like to, and still plan to, try and find a method for using S/C in multiple windows. I'm not quite ready to give up on that yet. Since that's not on your roadmap, I won't bother you further with that, unless you ever decide that's a worthwhile pursuit.

                     

                    However, could I bother you to weigh in on question #2? I'm sure I'm missing something there, in spite of having seen, and learned much from, all your and Jason's postings on the topic, including the latest you mentioned. I've also watched the DevCon recording of your session, and attending Jason's presentation of the topic at POE. (Regrettably, I missed your session at POE. )

                     

                    It's possible (probable ) that I'm just dense, but it seems like there's more to the globals-only connector table than just preventing record-locking. If that really is the only reason, though, then using a sessions or windows table there might be the wiggle room I need to make the multi-window thing work and still get the benefits I'm hoping for from the S/C model.

                     

                    Chris Cain

                    Extensitech

                    • 7. Re: Selector Connector Questions
                      Todd Geist

                      On multiple windows...

                       

                      Well "dangerous" might be too strong a word.  But it is easy for developers to get into a scenarios where records are locked in other windows, and scripts start silently failing due to record locking. Plus they are a pain to manage on Windows.  Yes it is all manageable, but only a great cost.  If I absolutely must show to records side by side its easy to do without using separate windows. So in the long run I just see no value in the added complexity.

                       

                      Now on to #2

                       

                      This is not about record locking the record you are on.  Or in record locking a Session Table. Its about making sure that any shared resources that pass through Selector and Connector don't get locked from other users while a user is making use of them.

                       

                      For example.  If you are on an Invoice Table and you want to make a new Customer Record, you can do that easily by clearing the Customer ID Global in the Selector table and setting a field the Selected::Customer table.  That'll create the record.  And it will Lock the new Customer Record Open, until you commit it.

                       

                      The path From Invoices to Selected Customer Looks like this.

                       

                      Invoices -> CONNECTOR -> SELECTOR -> selected_Customer

                       

                      Remember CONNECTOR and SELECTOR only have one record ( and they must or else the whole thing falls apart). If that one record Locks that means that no other user could use them to create records or edit records.  It wouldn't just prevent another user from creating a new Customer record from Invoices, it would stop all attempts to create or edit records through  CONNECTOR->SELECTOR, from anywhere.

                       

                      A big problem SELECTOR CONNECTOR solves is the ability to create, edit and delete records from all over your graph. In fact the same script that can create a Customer from Invoices, can probably Create a Customer from somewhere else like Projects. Thats because this:

                       

                           Projects -> CONNECTOR -> SELECTOR -> selected_Customer


                      Is roughly equivalent to this


                          Invoices -> CONNECTOR -> SELECTOR -> selected_Customer


                      CONNECTOR sort of makes all the TOs connected to it equivalent, at least to the extent that they can all "see the same context"

                       

                      None of that would work if SELECTOR and CONNECTOR were allowed to be "Lockable".  The first user to lock SELECTOR and CONNECTOR would stop all other scripts from making use of the the shared context.  So therefor we only use Globals in SELECTOR and CONNECTOR.

                       

                      Hope that helps :-)

                       

                      Todd

                      • 8. Re: Selector Connector Questions
                        Todd Geist

                        I'll also add a comment about #3

                         

                        You can certainly do both SELECTION and CONNECTION in one table. Lots of people do.  Neither Jason or I do because we find we like the Organizational layer it provides.

                         

                        I think we FileMaker Developers are loath to add new Tables because of the old 50 table limit in pre FileMaker 7 days.  That limit is gone.  Some people will claim that is slower to add another TO, but any claim that is not accompanied by a real world test that proves such a claim, might as well as be superstition.

                         

                        So if there is no limit on tables, and it its not provable slower to use more, why not use them as organizational tools?

                         

                        Clay Maeckel, senior architect at FileMaker Inc, said it was like we were using Tables as "Folders for Fields"  and he didn't see a problem with it.

                         

                        I like that "Folders for Fields"

                         

                        Todd

                        • 9. Re: Selector Connector Questions
                          Todd Geist

                          and what the heck why not #4 :-)

                           

                          We don't use Global Calcs for much, they are a major pain in the butt.  SELECTOR and CONNECTOR only connect and select and we don't find much of a need for globals calcs there, maybe a "constant" or something, but thats it.

                           

                          Calcs that don't rely on the current record can go in another single record Utility Table if you like. And since they are CONNECTED to everything else they can be unstored and will evaluate correctly on any where in your shared context.

                           

                          That way you can have the same field ( from your Utility Table ) displayed on every layout but have it's result be different based on some un-stored calculation.  So things like a calculated graphic that depends on the Layout Name work great in this scenario.

                           

                          Hope that helps too :-)

                           

                          Todd

                          • 10. Re: Selector Connector Questions
                            Extensitech

                            Wow, thanks for all your input!

                             

                            So... If I were to use a sessions table for the connector TO (or even a table with a record for the each window instance of this one user's session) and I were to create the record from your example (Invoices -> CONNECTOR -> selected_Customer), I would still lock the record in the selected_Customer, and still wouldn't interfere with other users in the connector table since no other users are going through this user's session record. I could also still control the transaction by clearing/resetting the customer key in connector without committing. (Gawd, am I nervous saying this to the acknowleged "transactions" guru... I hope I didn't just say something unbearably stupid! )

                             

                            Would this still accomplish the goals of the connector table, even though it's not all globals? I seem to recall some mention of the globals-only table being necessary to prevent FM (particularly iOS) from having to evaluate every other table in the solution because each of them would potentially have related records. I've mentioned this before, though, and no one seems to know what I'm talking about. Did I just make that part up? Or perhaps is my whole worry about unisolated TOGs on iOS a misunderstanding of the results I've seen? (This last is very possible. My work in iOS has been pretty limited and "one-off", and not subject to the scrutiny I usually give FMP work.)

                             

                            Chris Cain

                            Extensitech

                            • 11. Re: Selector Connector Questions
                              Extensitech

                              "Folders for Fields" +1

                               

                              I think I finally caught on that the selector table was an organizational tool, rather than so much a functional one.

                               

                              I was going to ask about the performance impact of stringing together these types of tables as organizational tools, but you read my mind, I think.

                               

                              I like the idea a lot, and since our RG is already divided into columns for modules and now (potentially) for S/C-style interface TOGs, I'm considering placing a "connector" TO at the head of each column, for neatness and also as kind of a "super-anchor", both on the RG and in the naming convention.

                               

                              I was having a bit of trouble trying this, but given your explanation, I'm pretty sure it was because of one or more other things I'm doing oddly, or outright incorrectly, so I'm going to keep experimenting.

                               

                              I'll let you know if any of my superstitions turn out to have any kernels of truth.

                               

                              Chris Cain

                              Extensitech

                              • 12. Re: Selector Connector Questions
                                Extensitech

                                I think what I was trying to get at was whether I could use a global calc to calculate the focus window instance, and use that to relate to my session windows table. I think from what I've since learned (here and through some other research) this isn't going to work reliably.

                                 

                                Still, glad to hear that I'm not the only one thinks that global calcs are (at best) a "pain in the butt".

                                 

                                Chris Cain

                                Extensitech

                                • 13. Re: Selector Connector Questions
                                  Todd Geist

                                  No sorry that won't work.  CONNECTOR needs to be a single record.  Thats how you get the benefit of the shared context. More than one record will break the xJoin connection to everything else.

                                   

                                  :-(

                                   

                                  Todd

                                  • 14. Re: Selector Connector Questions
                                    Extensitech

                                    Aha! I think I'm seeing the bit that wasn't sinking in.

                                     

                                    However if, instead of the Cartesian, each anchor had a calculated session key (unstored, equal to a global field set when the session began), could one not relate each of the AB tables to the connector (session) table that way? Since the session key is unstored, that wouldn't inadvertently form a relationship to other anchors, but would only related to the one session record, and from the session record I could still link to the common interface TOGs, create locked new records via those relationships...

                                     

                                    Sorry to keep pushing. I can be pretty stubborn tenacious at times, and I really want to find a way forward that will work well with our other tools.

                                     

                                    I know, I know... the hazards of a "monolith". But perhaps you could bear with me and think of this as a really comprehensive modular widget...

                                     

                                    Thank you.

                                     

                                    Chris Cain

                                    Extensitech

                                    1 2 Previous Next