Skip navigation

Monthly Archives: February 2011

The problem:

This simple page highlighted a problem on a web application using Prototype javascript library and a unassuming function name.

<html>

<head>
<script src=”prototype.js” ></script>
<script>
 function next(e) {
  alert(“window id is ” + window.id);
  alert(“a id is ” + $(myA).id);
  alert(this.id);
 }

</script>
</head>
<body id=”myBody” >

 <a id=”myA” href=”#” onClick=”next();return false;”>Click</a>
</body>

</html>

It was found that this page behaved as expected in IE (v7) but not in Firefox, Chrome or Safari. The onClick handler did not appear to be called.

Well the problem is due to a name clash we were completely unaware of. next is a function that prototype.js extends html element objects with. Our onClick handler turned out to be calling Element.next instead of our global javascript function.

To see this edit the onClick code,  replacing next() with alert(next).

The onClick handler uses the <a> element as its context and looks for a function in the local context before widening its search all the way up to the DOM global context (where our function is). In non-IE browsers it finds next is a method belonging to the Element object and executes it. In IE it does not find the next method until it finds our global function.

The solution:

Add an observer rather than an onClick function.

$('myA').observe('click', next);

Why? Prototype themselves explain why IE behaves differently.

I am currently wanting to add some security to all the HTTP requests received by our application. The application is based on Spring 3 with Spring MVC controllers. I realise the best way to apply this cross-cutting behaviour is with an aspect.

Now Spring MVC supports interceptors, designed to perform just this sort of thing and the Spring minds that know advocate this simple solution (or at least Jim White does).

MVC interceptors do provide easy access to the model but only in the post handler. This won’t work for introducing security as the controller may have damaged the database inside the controller! So the remaining solution is to use AOP. Using an around method I can get to the model if it is normally an argument of the controller method handling the HTTP request.

More on how this goes when I get it working.

When trying to put together a simple Spring/Hibernate JPA application I discovered (http://maven.40175.n5.nabble.com/adding-hibernate-dependency-missing-transaction-artifact-td137166.html) that the Maven dependency for JTA is missing.

It manifested itself as the following Maven error:

Missing artifact javax.transaction:jta:jar:1.0.1B:compile

I needed to download and include it separately. Thanks to the many who have been here before.

+ Oh yes, I forgot. I downloaded it from here.

Design a site like this with WordPress.com
Get started