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
A Site is just a "container" that allows you to expose Interfaces (whether as native UIs or Start forms on process models). The UIs should be fully testable as stand0-alone objects. What sorts of errors are you encountering?
all sorts, but usually the issue is the data that comes in when testing through a site is different than the data we get when testing through the editor. Unfortunately since we can't see that data, it makes troubleshooting troublesome.
Sounds to me like there's 2 things to attend to here:
1) I do navigate to the relevant ui object, the problem is I don't know what data the object is getting because opening the object just gives me the test data, not whatever the site is throwing at me.
2) Yes, but there could be dozens of variables and/or sources of data and narrowing them down without seeing what data I'm getting in the site is burdensome.
The top level interface in a site page will never get any data passed to rule inputs. Loading that interface into the editor should give you full debugging capabilities.
I'm still confused as to why you think the data used in a Site context is any different from the User Interface that is added to that Site? The top-level UI in a Site cannot have any rule inputs (there's nowhere to pass values to it from the containing Site). So: the top-level UI must be self-sufficient. So if you open it up in the Site or as the UI its behaviour will be identical.
Whilst I understand the thrust of adding "debug" to the front-end (which I view as an unnecessary overhead), the whole rationale for having a toolkit like the Appian Designer is to ensure each object is completely and exhaustively tested before it is ever integrated with another object. In the same environment the behaviour of a UI should be identical whether stand-alone or contained in a Site (the only possible difference might be driven by the role of the User doing the testing i.e. difference between a System Admin account and a a Basic user account).