In vision it was a simple message box, wasn’t sure where this stuff went when testing the client.Thx, jake
If you just use the
stdout and the way Perspective works.
If you’re using
system.perspective.print (recommended) then you can choose to log to a few different targets - the gateway, the ‘client’ (browser console, effectively) or both.
Where’s the browser console, I’m assuming the client is just a browser wrapped in an app, but I didn’t see anyway to bring up a console.Thx, jake
Well, it depends. In the native apps, as far as I know there’s no way to access the console outside of app-developer-level-stuff. Workstation I’m not sure about - I think it would depend on what mode you’re in. In a regular browser session, just open the dev tools (I think Ctrl + Shift + I works across most browsers).
That doesn’t seem to work, how do others debug scripts, I can’t really do it at the gateway since I’m getting 1500 or so log lines per minute without trying to debug something, I’d never see anything from the app I’m debugging.Thx, Jake
Anyone else have any thoughts?
I usually just use the normal print statement to log to the wrapper. It’s a bit of a pain for debugging (but then, tbh, it always has been without a debugger with step buttons…)
If it’s a script within a non-client scope e.g. Gateway events (for Perspective, all scripts are gateway-scoped), then I’ll run it in the script playground first to get it doing what I want, replacing the page/view parts with other things (as obviously you can’t update a view component from a script console)
k, I’ll try to tail and grep on the server to get anything useful.Thx, jake
I set up a database table with columns for info such as severity, origin, message, time, scope, and IP address. I also created a global python class that has methods to insert rows into the table for different types of logs. This is still a work in progress, but at the moment I have methods that can log exceptions, stack traces, and simple debug strings. I have severity levels set up for different scenarios such as fatal exceptions, handled exceptions, harmless debug messages, etc. It has been handier for me to use than the wrapper logs and gateway logs as I have SSMS open most of the time anyway, and it allows for filtering the logs by different parameters, so that I don’t have to pick through thousands of logs messages.
I set this up initially so that I could have one location for client and gateway scoped logs, as well as a way to see error messages without having to have the client device in my hand.
That’s a sweet solution. I did finally find the problem session.props.auth.user.userName isn’t working, not sure how to get the username, it’s simple in vision.
What about just using a Logger? (system.util.getLogger)
This has all of that, and you can simply filter for logs from your logger name within the gateway logs
From the manual, super simple example:
The issue that I have run into using the native Logger is that client logs are not available to me at my workstation unless I am the one running the client. I wanted a way to check client logs without having to have the client device in front of me, which can be difficult for a variety of reasons. Is there a way to make client-side logs that are available to me remotely using system.util.getLogger?
Perspective logs to the gateway wrapper, not in the browser/client, unless you deliberately use system.perspective.print().
For perspective all the logger stuff goes to the gateway. There isn’t any client logger anymore. So using system.misc.getLogger will log to the gateway everytime.
Logger logs go into the gateway logs accessed via the gateway status webpage. If you have access to the Designer remotely, then you have access to the gateway status page to view the logger logs