Do transactions re-associate detached objects?

It appears that wrapping a manager method in a transaction via Hibernate's AOP functionality, does not automatically re-associate any detached objects passed into the method to the session. You'll need to do this manually.

A Spring WebFlow Gotcha

If your flow definition has a element and its "if" attribute contains two or more clauses joined by the AND logical connector, make sure to use & amp;& amp; (no spaces) instead of &&, because && breaks XML validation.

Hibernate Intricacies

Forgive me please if the following post is not 100% clear.

Imagine this: You've got a Proposal object with a List<Resource> field. Each Resource has a Map<ResourceAttribute> field. You're using Hibernate, and the Resource.hbm.xml contains a <map> element with cascade="all-delete-orphan". If you call Session.save(resource) for a particular resource belonging to a proposal, and later call Session.update(proposal) for that proposal, you will get the following exception - Don't change the reference to a collection with cascade="all-delete-orphan".

Obviously you haven't directly changed the resource's reference to its map of attributes, but, somehow, by saving the resource directly, instead of jumping up a level and saving the proposal to which it belongs, you're causing Hibernate to consider the reference changed.

Extending JavaScript's onsubmit method

Suppose your page has a form, and you want to extend its onsubmit method programatically. Here's one way to go about it:

form = document.getElementById("form");
form.realSubmit = form.onsubmit;
form.onsubmit = function () {
  alert("before the original onsubmit");
  this.realSubmit();
}

(Based on Orc Scorcher's response to this thread on www.webdeveloper.com)

A Queue of AJAX Requests

Till now, I hadn't written code to fire off a number of AJAX requests with callbacks in rapid succession. The code wasn't working as hoped, and usually only the last callback would succeed. This is because a new AJAX request is being made before the callback for the previous request has finished executing. Due to their being only one XMLHttpRequest, concurrency issues prevail. A possible solution involves creating a queue for the requests and only firing the next request once the callback for the previous one has completed.