Site Testing

Certified Senior Developer

An often occuring frustration when testing out an interface is that it will work fine within the interface editor, but once we throw it on a site, something goes wrong. That wouldn't be too big a deal as it's all part of development, but whenever we test interfaces on a site, there is no way to see what values the variables are getting for diagnostic purposes. We can hide/show the components on the site, but is there some way for developers to also see variable values? 

  Discussion posts and replies are publicly visible

Parents
  • 0
    Certified Lead Developer

    I assume you might have some variables / queries that depend on the user viewing the form.  A technique I've developed gradually is, instead of throwing the loggedInUser() function all over your interface(s), is to capture it only once into a local variable and then using that in queries, group membership checks, etc.  For debugging purposes, this is a big help because then we can instead temporarily change the "local!currentUser" variable delcaration to refer manually to a username instead of loggedInUser(), and make sure things still work.

Reply
  • 0
    Certified Lead Developer

    I assume you might have some variables / queries that depend on the user viewing the form.  A technique I've developed gradually is, instead of throwing the loggedInUser() function all over your interface(s), is to capture it only once into a local variable and then using that in queries, group membership checks, etc.  For debugging purposes, this is a big help because then we can instead temporarily change the "local!currentUser" variable delcaration to refer manually to a username instead of loggedInUser(), and make sure things still work.

Children
  • I assume you might have some variables / queries that depend on the user viewing the form.  A technique I've developed gradually is, instead of throwing the loggedInUser() function all over your interface(s), is to capture it only once into a local variable and then using that in queries, group membership checks, etc.  For debugging purposes, this is a big help because then we can instead temporarily change the "local!currentUser" variable delcaration to refer manually to a username instead of loggedInUser(), and make sure things still work.

    100% agree, aside from my debugging hide/show, always always have a local!user: loggedinuser() type variable declared at the top of the interface, and reference local!user throughout (passing to child interfaces as well).  Being able to change this to a value in one line for debugging such as local!user: touser("john.doe"), and test, is huge. 

    My case for loggedinuser() within the debugging only section is so I can throw it on other developers' interfaces that do not have local!user declared for whatever reason.

  • 0
    Certified Lead Developer
    in reply to Mike Schmitt

    As an advanced tactic, in some interfaces I define "local!currentUser" like this, to enable myself to throw in an arbitrary username as needed, and switch to it instantly just by commenting out the line with "loggedInUser()".

    local!currentUser: a!refreshVariable(
        value: {
          loggedInUser(),
          "throwawayuser823498"
        }[1],
        refreshAlways: true()
      ),

  • 0
    Certified Senior Developer
    in reply to Mike Schmitt

    These sound like awesome ideas. I just need to go in and rejigger everyone else's interfaces for it Slight smile

    Thanks for the tips