<%= %>
) before Underscore ever gets a chance to use it. I assume evaluations would also be consumed by GSP. Took me a while to figure this out, so I thought I'd raise it up as a concern. Underscore.js does give you a way to change the delimiters using regexes.
Thursday, October 13, 2011
Grails GSPs consume Underscore.js ERB-style interpolation delimiters
Wednesday, October 12, 2011
Rationale for CoffeeScript's 'Fat Arrow' syntax
I was building a Backbone.View today (in JavaScript) and had to deal with this binding. In my JavaScript, I wanted to call fadeOut on the view's el property (which happens to be a jQuery wrapped element). Without using the jQuery proxy method to bind this appropriately, my statement of 'this.el.fadeOut();' will not work. The this reference is no longer the view at the point I'm using it in the anonymous function; the context for this has changed within the anonymous function declaration. The correct JavaScript code is below.
var MyView = Backbone.View.extend({
initialize: function() {
this.template = _.template($('#my-template').html(), this.model.toJSON());
this.render();
},
render: function() {
this.el.html(this.template);
return this;
},
events: {
"click button#doSomethingButton": "doSomething",
},
doSomething: function(e) {
this.model.set({someValue: $('#someValueTextField').val()});
var promise = this.model.doSomethingOnModel();
promise.done($.proxy(function() {
this.el.fadeOut();
}, this)).fail(function() {
alert('Failed to check sequence uniqueness.');
});
}
});
So how does this relate to CoffeeScript? Well, the fat arrow operator is performing the proxying of the 'this' reference for you. If I wrote the above in CoffeeScript, I could write the done callback as:
…
promise.done => @el.fadeOut()
…
Chaining the done and the fail callbacks would necessitate the use of parentheses, but still very succinct. Score one for CoffeeScript!
Wednesday, October 05, 2011
Using JDBC URLs containing LDAP URI to connect to Oracle databases within Grails
I'm working on a Grails application that needs to connect to a Oracle database using a LDAP context. The URL format is something like the following:
jdbc:oracle:thin:@ldap://tns.mycompany.com:389/marketing,cn=OracleContext,dc=com,dc=marketing
I'm also not using the Grails DataSource.groovy configuration for this. I'm managing a separate DataSource in the resources.groovy using Spring DSL. I'm using the org.springframework.jdbc.datasource.DriverManagerDataSource. I have not tried this with the standard DataSource.groovy stuff. When I first tried using this, I would get an exception with the following text: "javax.naming.NotContextException Not an instance of DirContext". There seems to be a bug with the Spring LDAP and the SimpleNamingContextBuilder class. Basically the SimpleNamingContextBuilder returns a Context implementation, not a DirContext implementation. You can work around this in Grails by adding the following to the Config.groovy file:
grails.naming.entries = null
Problem solved. The DataSource now bootstraps correctly and I can go on my merry way. Kudos to Luke Daley for bringing this to my attention.
Monday, October 03, 2011
Hiking around in Big Woods State Parks
Big Woods State Park |