Occam's dollar sign
Category xpages
A few of us here at HQ were just discussing the value of having many eyes on the same bug, given how often the underlying cause is some small thing that's been staring us in the face the whole time, just begging to be found. Just yesterday, while troubleshooting a problem for a customer, I saw a perfect example of that which, during today's discussion, I couldn't resist jokingly referring to as "Occam's dollar sign".
For those not familiar with "Occam's razor", it's a scientific principle originating from the Latin phrase, "entia non sunt multiplicanda praeter necessitatem", roughly translated as "entities must not be multiplied beyond necessity". Or, as it was paraphrased in the movie "Contact", "all things being equal, the simplest explanation tends to be the right one."
The issue at hand yesterday was that a SSJS call to getComponent() was returning null even though it was passed a valid ID. After checking a couple other things that I thought might be the cause, I noticed something that looked a bit odd. When coding an XPage, I tend to spend most of my time in the XML source instead of the GUI Design tab... not only does that suit my personal preferences, but I'm also seeing everything, not just the properties that display on the portion of the GUI I've selected. So I've gotten used to seeing dynamic properties that look a little something like this:
Although it didn't jump out at me immediately, I soon noticed that the failing code looked a little something like this:
Of course, it wasn't bold in the code, but you get the point. I remembered that, while looking at example code from various sources, I've occasionally seen a dollar instead of a pound, but not in my own code - which made me wonder why. Most SSJS events allow you to choose between "compute dynamically" and "compute on page load" (though, in some cases, this option only appears if you launch the script editor from the "right" location). As I soon found out, the pound sign means "compute dynamically", a dollar sign means "compute on page load"... which explains why I never see the $ in my own code, because I don't use the "compute on page load" option - mostly because I haven't seen any documentation yet describing scenarios where that option is preferable.
In short, $ means that the computation occurs later... evidently at some point after the ID you enter gets translated into the funky namespaced ID the browser sees... which means that, if you pass the original ID to getComponent(), that ID no longer exists, and getComponent() returns null.
All things being equal...
A few of us here at HQ were just discussing the value of having many eyes on the same bug, given how often the underlying cause is some small thing that's been staring us in the face the whole time, just begging to be found. Just yesterday, while troubleshooting a problem for a customer, I saw a perfect example of that which, during today's discussion, I couldn't resist jokingly referring to as "Occam's dollar sign".
For those not familiar with "Occam's razor", it's a scientific principle originating from the Latin phrase, "entia non sunt multiplicanda praeter necessitatem", roughly translated as "entities must not be multiplied beyond necessity". Or, as it was paraphrased in the movie "Contact", "all things being equal, the simplest explanation tends to be the right one."
The issue at hand yesterday was that a SSJS call to getComponent() was returning null even though it was passed a valid ID. After checking a couple other things that I thought might be the cause, I noticed something that looked a bit odd. When coding an XPage, I tend to spend most of my time in the XML source instead of the GUI Design tab... not only does that suit my personal preferences, but I'm also seeing everything, not just the properties that display on the portion of the GUI I've selected. So I've gotten used to seeing dynamic properties that look a little something like this:
"#{javascript:return something;}"
Although it didn't jump out at me immediately, I soon noticed that the failing code looked a little something like this:
"${javascript:return something;}"
Of course, it wasn't bold in the code, but you get the point. I remembered that, while looking at example code from various sources, I've occasionally seen a dollar instead of a pound, but not in my own code - which made me wonder why. Most SSJS events allow you to choose between "compute dynamically" and "compute on page load" (though, in some cases, this option only appears if you launch the script editor from the "right" location). As I soon found out, the pound sign means "compute dynamically", a dollar sign means "compute on page load"... which explains why I never see the $ in my own code, because I don't use the "compute on page load" option - mostly because I haven't seen any documentation yet describing scenarios where that option is preferable.
In short, $ means that the computation occurs later... evidently at some point after the ID you enter gets translated into the funky namespaced ID the browser sees... which means that, if you pass the original ID to getComponent(), that ID no longer exists, and getComponent() returns null.
All things being equal...
Comments
{ Link }
Posted by Rob McDonagh At 07:16:28 PM On 03/04/2009 | - Website - |