The .ready() method is generally incompatible with the <body onload=""> attribute. If load must be used, either do not use .ready() or use jQuery's .load() method to attach load event handlers to the window or to more specific items, like images.
The .ready() function will be called earlier than the onload handler and it is possible for a developer to declare change handlers in the page that are fired before the onload handler is called meaning that the comparison object does not represent the original state of the object. It is not easy to spot problems with this as the error may manifest as a failure to execute a SPARQL Update query (due to a timestamp mismatch). The advice on the jQuery site is good advice. I moved the call to calli.copyResourceData() into the .ready() function so I could ensure it was called before any possible changes to the data.
Perhaps the default template could be modified as follows:
<head>
<title resource="?this">{rdfs:label}</title>
<script type="text/javascript">
//<![CDATA[
// ensure this is called before any possible changes to the form data
$(document).ready(function() {
comparison=calli.copyResourceData('#form');
});
//]]>
</script>
</head>
<body resource="?this">
If the developer uses an external javascript file, they can move this JS fragment to it but at least they are explicitly managing the call ordering.
I am concerned about introducing { and } into a default XHTML template, since these are also used to identify variable and path expressions. Perhaps including this code (inline) after the form is better.
The default edit template ([http://callimachusproject.org/docs/1.4/callimachus-for-web-developers.docbook?view#Edit_template]) uses the onload event to set up a comparison object for managing data changes in the form. But, the jQuery documentation says:
The .ready() function will be called earlier than the onload handler and it is possible for a developer to declare change handlers in the page that are fired before the onload handler is called meaning that the comparison object does not represent the original state of the object. It is not easy to spot problems with this as the error may manifest as a failure to execute a SPARQL Update query (due to a timestamp mismatch). The advice on the jQuery site is good advice. I moved the call to calli.copyResourceData() into the .ready() function so I could ensure it was called before any possible changes to the data.
Perhaps the default template could be modified as follows:
If the developer uses an external javascript file, they can move this JS fragment to it but at least they are explicitly managing the call ordering.