Globals are too global

Discussion created by flukey on Feb 4, 2018
Latest reply on Feb 4, 2018 by DavidJondreau

This may serve as my Sunday morning rant before coffee, but here goes.  It's a little long so please bear with me.


Many times in the past I have wanted to take advantage of using multiple windows in an application only to be frustrated by one simple thing,  "Global fields are too global".  In developing a typical application one typically puts a portal on a layout showing related child records.  Sometimes however you want to show another portal with either related grandchild records, or records from another table not necessarily directly related to the layout's base TO.  Say for example I click on a line item in my child portal and based on the item selected I want to show some related data in another portal.  The typical way to do this with the current level of FMP functionality is to add a global field to the layout's base table and use that to reference a TO with the grandchild records that you need to base the additional portal on.


All that is simple enough and is something I have done successfully many times.  However in trying to have a multi-window application this approach is not possible if you want to have different windows looking at different records from the same base table.  Since the global field is "global",  all windows in the client session get the same value, so that setting the global in one window affects what is being shown in other windows referencing the same table.


The way that this has been typically solved in the past is to create a session table and base each layout on it's own record in this session table, giving each window the ability to have its own independent values that can be used to point to anything we want, without affecting other window sessions.  However this complicates the solution, requiring a lot more work and development time than normal, and also kills a lot of the basic functionality we get from using the native operational model built into FMP, since things list list view layouts still need to be based on a TO of the table with the records we want to list..


What we need is a new form of global field.  Lets call it a "Wibal" for now, i.e. a window local "global" field.  In the same way that a window can have its own found set of a TO, and basically inherits and operates on its own reference to a TO independent of other windows (other than record locking), we need to have a version of a global field that is local to each window as it is opened.  In the same way that each client session inherits globals from the file being served and each client can independently manipulate these globals without affecting the globals of other client sessions, these Wibals would operate and be independent of the same Wibals in another window. This would allow us to have truly independent multi-window flexibility.


While we are on the subject of globals, let's take it one step further and have three levels of globals.


1) a file global field that is truly global to the entire application. This can be useful for things like global constants or just some field on a layout that is the same throughout the application session.


2) a table global field. This is what we have now and lets us do several useful things that are related to that table, and even serves right now as a file global since it can be set/read from any context at any time.


3) the Wibal field, as described above, would allow us to have a field that is local to the TO session for the window.


4) and if it is not pushing it too much, a final field type that is not global to the file, table or window, but is local to the record in that setting its value only affects its value relative to the current client session, but other clients have their own version of the value in this record independent of the other clients being served the same record.  This would let us do things like being able to easily select records from a list of records, without being affected by what some other client or window is selecting in their own session. Let's call this one a "Ribal", i.e. a record local "global" field.


Hopefully this all makes some sense.


That's it for my morning rant.  If some think that this has merit then I will post it to the product ideas/feature request section.  Alternatively, if other developers have already figured out a simple elegant way to solve the multi window issue,  please enlighten me as I am just a little peeved right now.