Show ’n’ tell III: Domino debugging
at 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?
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: 0.01em 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!
Posted at 06:48 GMT on 09 Mar 2006 | Categories: | |
show-n-tell thursday
lotus notes domino (8 comments)
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!
Oh, and: you AttentionSeekingWhore, you!
Thanks
And to share the attention - @4 GREAT IDEA... if only...