How to debug macros
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎02-01-2017 07:40 AM
I am using Istanbul version
Please explain how to debug macro?
I set this GlideProperties.set ( 'glide.ui.template.trace' , true ) ;
I saw this
<g:breakpoint/>
This tag can be used to display the current Jelly variables and their values in the log. Be sure to remove this tag before going to production.
in documentation but how to use this? Inside macro code? Where? How can I see the log?
Please post some example if possible

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎02-01-2017 09:21 AM
You put it in the macro code and then it puts the data in the system log.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎02-01-2017 09:31 AM
As a side note I have always found it easier to just use gs.print or gs.log to dump things out for Jelly you can just do things like ${MYVAR} to see what it is when the page or macro displays.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎02-01-2017 10:16 AM
Using <g:breakpoint /> throws out a lot of variables, beyond the ones you are creating. Of course you can fine tune what variable you are looking for by writing it as <g:breakpoint var="[variable_name_comes_here" />. This can go anywhere in the UI Macro as long as it is after the variable declaration. For example:
<j:set var="jvar_testVariable" value="${gs.hasRole('admin')}" />
<g:breakpoint var="jvar_testVariable" />
To see the output you would, of course, need to enable Session Debug > Debug Log (or look at the logs, but I prefer session debug) and you will get output that looks something like this:
10:04:47.985: <<< BREAKPOINT TAG START <<<
10:04:47.985: JVAR: jvar_testVariable(java.lang.String) true
10:04:47.985: >>> BREAKPOINT TAG END >>>
Regarding the glide.ui.template.trace property, this shows the call stack of the Jelly code on the application server (.xml) files. You will not have access to look at the actual code, but it is a good tool for Customer Support to debug issues and problems, which we use in tandem with the breakpoint property. Again you will need to look at the logs or use session debug. There's quite a lot to see, but I've attached a sample showing the property and the breakpoint used together.
However, I agree with Drew. It's my preference to stick to gs.print and gs.log rather than <g:breakpoint />.
Oh and don't forget. You would want to disable that property when you've finished doing whatever it is you were doing. Otherwise you'd end up spamming the logs when there's no issue, and Customer Support will .
Hope this helps.
EDIT: Fixed a typo and improved some highlighting.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎02-01-2017 10:53 AM