Avoid coupling new features to layout objects

Idea created by Chris Irvine on Dec 7, 2015
    Active
    Score17

    There have been some excellent new features added during the recent major FileMaker releases. Unfortunately, some of those features were tightly coupled to literal objects on layouts. Now, in a certain cases this makes sense, because they directly relate to the design surface. But, in other cases, the usefulness of those features were significantly restricted.

     

    Going forward, please carefully decide where a capability is most needed, and if there is a strong case for coupling it to the interface, or not.
    Also, whenever possible, retool or enhance older features so that we can make better use of them. Specifically, many of these features would be hugely beneficial without requiring a field on layout and should be supported on server execution or in hidden or Virtual windows.

     

    I'll reference a few past examples, some of them already have ideas posted for them. I'm sure there are many more. (If anyone is particularly motivated on one of these specific limitations, feel free to fan out a specific idea request and I'll mention it here.)

     

    Insert From URL

    "Select entire contents: replaces the contents of a field. If you do not select this option, Insert From URL inserts the content from the URL at the insertion point or at the end of the field's data." WHAT!#!# Sorry, but the majority use case for downloading URL data doesn't belong here. One suggested improvement was Return Script Step Results to Variable. This isn't a bad idea, but maybe there are operating system reasons why the download needs to be stored into a field, such as background downloading. Either way, decouple URL retrieval from the interface.

     

    Insert PDF

    Many of us need to import PDF's into container fields. Additionally, many of us like the interactive container display capability. But I'm not sure why literal interactive containers on a layout are important to this insert task. Maybe I'm missing something on this one.

     

    Refresh Window [Flush cached join results]

    Sometimes we need to reload foreign records for pure scripting reasons, a [rendered] window doesn't necessarily come into play. The point here is that discarding cached data and painting the window again don't necessarily go together.

     

    Delete One [Foreign] Record

    We have pretty solid transaction capabilities for creating records and editing records with a single revert/commit option. This can all be done without any interface interaction and even a completely blank layout. However, deleting record(s) during a transaction still requires a literal portal and the Delete Portal Row step.

     

    Pause/Resume Script [ Duration (seconds): $n ]

    This one is mostly historical, but there are good reasons that developers need to let a little time pass. This shouldn't imply that we want to render UI on screen, confuse the user, or load foreign display data over the WAN.

     

    I'm sure there are probably a few more, but these are the ones that I bump into pretty regularly.