El Sábado 15 Julio 2006 14:58, Christopher Arndt escribió: CA> CA> CA> No, he is catching the exception with "except Exception"* and returns a CA> different dict with just the error message. yep, that's true CA> And that's where the error CA> lies: Javier, you have to check in your JS callback function, if the the CA> received object really contains an id (untested): No, I don't have to. That is the idea of the return statement within the if (d["tg_errors"]) block, to not execute anything else.
CA> function dos (d) {
CA> if (d["tg_errors"]) {
CA> alert(d["tg_errors"]);
CA> return;
CA> }
CA> if (d['id']) {
CA> select = document.getElementsByName("persons")[0];
CA> last = select.options[select.options.length-1];
CA> removeElement(last);
CA> appendChildNodes(select,
CA> OPTION({"value":d["id"]},d["nombre"]),last);
CA> } else {
CA> alert("Error inserting name in database!");
CA> }
CA> }
CA>
CA> (Keep in mind that in JavaScript every statement ends with a semicolon.)
OK.
CA>
CA> * this is bad practice. Find out the type of exception that is raised
CA> when the key already exists in the database and just catch that.
Yes, I know I was going to get some comments about that... is the "I hadn't
near the sqlobject docs nearby" excuse works? :). Thanks for pointing out
that
--
Javier Rojas
GPG key:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xA1C57061
pgp3kNGfmNQCI.pgp
Description: PGP signature
