PreviousNext…

Show ’n’ tell III: Domino debugging

Show-n-tell Thursday logoAt the risk of coming across like some kind of whore (what the hell was that all about??) I herewith blight the interweb with another show-n-tell Thursday post! As with my others, it’s a pretty simple one. (a) because I am a simple soul and (b) well why not? Sometimes the old timers could do with looking at the simpler stuff, certainly I find that to be the case, and anyway hopefully some newer coders can pick up a trick or two as well.

Anyway, on to this week’s tip / hint / load-of-bollocks / call-it-what-you-will:

I still code occasionally (sometimes even at work!), and this is usually web development, often with Domino. The thing I love about Domino is the way you can build up dynamic pages so easily: regular readers will know what a fan I am of computed text. And then we have subforms—even computed subforms!—and we can mix in Lotusscript, Javascript, Java, agents, @formula, all that. ’s great. But you need to keep a careful eye on it all, especially if you’re a chump like me.

So, the last time I put together a reasonably big / fiddly web application in Domino, I tried something a little bit different, knocking up a simple debugging tool. So, if your typical Domino URI looks like this: …/somepath/somedb.nsf/someview?open&query=pants

… how about if you could just sling something like this in your address bar: …/somepath/somedb.nsf/someview?open&query=pants&debug=1, and lo, magically a panel appeared thus?

Screenshot of custom Domino debug pane

Quite handy eh? If you’re like me, you have all kinds of hidden fields and stuff, variables etc. (CGI or otherwise) that you use as you go along in developing a site, and you might hide / unhide them to figure out what’s happening. Well, why not just stick ’em in a purpose-made <div> and forget about them? Just wheel them all out when you need them. Simple, but effective.

So here’s what the <div> looks like—feel free to stick it anywhere that makes sense in your site design. I create the debug pane as a subform, and then bring it in to relevant forms using this formula:

@If(@UrlQueryString("debug") != ""; "$Debug"; "")

(where $Debug is the name of the subform, and we add “&debug=something” to the querystring to bring the pane up in the first place). How you actually populate the panel is up to you, but I’ll provide a couple of pointers in a bit. First up, some example code to style the debug pane. Then the pass-thru HTML to render it:

#debug
{
	border: .1em solid #ff0033;
	padding: 1em;
	font-family: monospace;
	font-size: 85%;
	background-color: #eee;
	color: #ff0033
}

[…]

<div id="debug">
	<h3>Debug pane</h3>
	<p>You're logged in as '<Computed Value>'. You have <Computed Value> access.<br>
	You also have the following ACL roles:<br/> <Computed Value>.</p>
	<ul>
		<li>SERVER_NAME is '<Computed Value>'</li>
		<li>Query is '<Computed Value>'</li>
		<li>Cookie: '<Computed Value>'</li>
		<li>View: '<Computed Value>'</li>
		<li>Special lookup field: '<Computed Value>'</li>
		<li>View count: '<Computed Value>'</li>
		<li>Agent message(s): 'AGENT_MESSAGE_FIELD'</li>
	</ul>
	<span style="position: relative; float: left;">
		<a href="<Computed Value>">Hide me</a>
	</span>
</div>

On to the last piece of the puzzle for now, namely how to populate some of the computed values above. For a start, this formula will cover off the access pieces:

REM {This covers the current user's access level};
var := @TextToNumber(@UserAccess(@DbName));
@Select(var; "Depositor"; "reader"; "Author"; "Editor"; "Designer"; "Manager")

REM {This lists their ACL roles};
@Implode(@UserRoles; ", ")

The agent message field may be useful in your environment if it’s anything like ours, where we don’t have access to check whether an agent has been appropriately signed for staging / production environments. You could access such data from your debug pane, or, as in this case, you could introduce a field to the debug pane with a default message in it. You then simple code your Webqueryopen agent (or whatever) to overwrite this field with an appropriate log message if it runs. If the agent doesn’t run, your default message stays.

There’s a lot of stuff you can add, but I like the basic technique: it’s simple, and easily extended. Stick it in your Domino toolbox, and you’re off!

Comments

  1. Wow, that is a heck of a lot easier/cleaner/saner than adding print statements and totally mucking up the workings of your application. I will definitely give this a try, and appreciate your thinking of it.

    It also gives me an idea about on-line demos we do. I could use the same sort of design to add a "What is going on in this demo?" play by play, so that somebody can run the demo, then run it "annotated" and have it show lines of code or even a changing value in the hidden div using JavaScript to update the values (with everything else computed).

    Excellent tip!Ben Langhinrichs#
  2. Ben, that's freaking brilliant. I throw that information in all the time to debug specific issues, but it would be so much simpler if it were always there anytime I wanted it. Nice. Very nice.

    Oh, and: you AttentionSeekingWhore, you!Rob McDonagh#
  3. That´s a great tip, very useful all the time !!.
    ThanksEliseo Sorto#
  4. On a related note, why can't there be a "Development server" switch in the Server Config and then "Entry not found in index" can become "Entry kilt not found in index pants". At least then you'd know roughly which of the 100 @dblookups on your form the error is coming from.Marcin Szczepanski#
  5. Just to give you all the credit :) you deserve - this is such a good idea - so much better than flicking hide-whens all the time!

    And to share the attention - @4 GREAT IDEA… if only…Laurette Rynne#
  6. I particularly like the HTML code for your div's background color… looks like the sound I make when I find something like this tip.Tim Tripcony#
  7. Very nice. Instead of @UserRoles , you might output the contents of @UserNamesList. This will show you all groups you're in (including all nestings!), as well as roles. This is very handy for figuring out why a user can't perform a given action in an application with complex security. Will Ryan#
  8. Yep, good catch Will—all sorts of things can go in there. I find the user roles / name lists stuff useful in the Notes client as well as on the web. As you point out, invaluable for troubleshooting application access issues. Users aren't too hot on the in-built stuff in the Notes client I find (Security icon in the taskbar etc.)Ben Poole#

Comments on this post are now closed.

About

I’m a software architect / developer / general IT wrangler specialising in web, mobile web and middleware using things like node.js, Java, C#, PHP, HTML5 and more.

Best described as a simpleton, but kindly. You can read more here.

";