On Dec 6, 2005, at 1:19 PM, Jeff Watkins wrote:
Bob Ippolito wrote:
In these kinds of situations I prefer *never* to dynamically
generate code. What I do instead is simply place a hidden input
element in the page conditionally with whatever value is
necessary, and the JavaScript code in the page will know what to
do with it. For example:
<input type="hidden" value="${message}" id="show_message"
py:if="show_message" />
and the (probably external to the page) script would look
something like:
addLoadEvent(function () {
var msg = getElement("show_message");
if (!msg) return;
alert(msg.value);
});
... or if I wasn't using MochiKit
(function () {
var old_onload = document.body["onload"];
document.body.onload = function () {
if (old_onload) old_onload();
var msg = document.getElementById("show_message");
if (!msg) return;
alert(msg.value);
};
})();
Of course, if the data you need to pass into JavaScript isn't
just a string, you should probably JSON encode it.
There are a couple reasons for using methods like this:
- It's hard enough to debug *static* JavaScript code
- You can test the JavaScript code independently from any server
stuff just by putting a test value in there and using py:attrs for
the dynamic value
- It's easy to do something with the data outside JavaScript using
only XML machinery (XSLT even).
-bob
Bob, I'm not certain what you're trying to get at here. No one's
suggested dynamically generating Javascript code at all. The
closest anyone's come is including or excluding a script block
based on a Python variable.
Which is still dynamically generated code. The fact that it's coming
in and out dynamically probably implies that there's also dynamic
data ending up in there too. Getting the dynamic stuff escaped
correctly, the code debugged, etc. is just not worth it. Don't
generate code (especially with something that's tailored for
generating something else entirely with different rules).
And off topic, is there some particular reason you don't like using
the DOM methods for adding event listeners? Your non-Mochikit
solution for adding a load handler is particularly opaque even to
someone like myself who regularly teaches JavaScript programming.
It makes the problem seem harder than it really is. (Yes, I know my
example didn't account for multiple onload handlers, but I usually
throw an exception rather than deal with browsers that are so old
they support neither addEventListener nor attachEvent.)
Yes, because it's less code and it works the same in all browsers.
If I took out the enclosing function (so as not to pollute the window
namespace) and the onload chaining, then it would be the simplest
version by far. I did those things because it's generic and
unobtrusive to other scripts, if it was my page and I knew what else
was in it then I wouldn't have bothered.
document.body.onload = function () {
}
rather than
if (some capability) {
callSomethingWithThreeArguments();
} else if (another capability) {
callSomethingWithTwoSimilarButNotIdenticalArguments();
} else {
fallBackToSomethingElseIfWeCare();
}
-bob
