Grails has a built-in URL constraint to check if a String value is a valid URL. We can use the constraint in our code to check for example that the user input http://www.mrhaki.com is valid and http://www.invalid.url is not. The basic URL validation checks the value according to standards RFC1034 and RFC1123. If want to allow other domain names, for example server names found in our internal network, we can add an extra parameter to the URL constraint. We can pass a regular expressions or a list of regular expressions for patterns that we want to allow to pass the validation. This way we can add IP addresses, domain names and even port values that are all considered valid. The regular expression is matched against the so called authority part of the URL. The authority part is a hostname, colon (:) and port number.
In the following sample code we define a simple command object with a String property address. In the constraints block we use the URL constraint. We assign a list of regular expression String values to the URL constraint. Each of the given expressions are valid authorities, we want the validation to be valid. Instead of a list of values we can also assign one value if needed. If we don't want to add extra valid authorities we can simple use the parameter true.
Continue reading →
In Grails we can define properties for services, controller, taglibs, Spring components and other components in the Spring application context through configuration. This is called property overriding in Spring terminology. This feature is very useful to define or override property values on components in the application context. We can define the property values in a beans{} block in Config.groovy. We can also load external configuration files, like property files and define property values in those.
With property overriding we don't have to look for property values via an injected GrailsApplication object and the config property of GrailsApplication. The code using the property value is now much cleaner and easier to test.
Continue reading →
Today a colleague asked a group of front-end developers how he would create a superelipse. His current solution was to use a svg mask to remove all non essential visual information. This solution however had a setback, because we used a mask to shield the edges we had no real transparency. Thus we were unable to effectively use it on more graphic backgrounds. I however thought it should be able to use canvas to provide the solution. The code below is my solution.
<canvas id="myCanvas" width="200" height="200"></canvas>
<script>
var canvas = document.getElementById('myCanvas');
var image = canvas.getContext('2d');
var width = canvas.width;
var height= canvas.height;
var img = document.createElement('IMG');
var shape = {
beginPath : function(node) {
image.beginPath();
image.moveTo(
node.x,
node.y
);
},
createCurve : function(curve, node) {
image.quadraticCurveTo(
curve.x,
curve.y,
node.x,
node.y
);
},
node : {
top_left : {
x : ((width/100)*20),
y : ((height/100)*5)
},
top_right : {
x : ((width/100)*80),
y : ((height/100)*5)
},
right_top :{
x : ((width/100)*95),
y : ((height/100)*20)
},
right_bottom :{
x : ((width/100)*95),
y : ((height/100)*80)
},
bottom_right : {
x : ((width/100)*80),
y : ((height/100)*95)
},
bottom_left : {
x : ((width/100)*20),
y : ((height/100)*95)
},
left_bottom : {
x : ((width/100)*5),
y : ((height/100)*80)
},
left_top : {
x : ((width/100)*5),
y : ((height/100)*20)
}
},
curve : {
top : {
x : ((width/100)*50),
y : 0
},
top_right : {
x : ((width/100)*92.5),
y : ((height/100)* 7.5)
},
right : {
x : width,
y : ((height/100)* 50)
},
bottom_right : {
x : ((width/100)*92.5),
y : ((height/100)*92.5)
},
bottom : {
x : ((width/100)*50),
y : height
},
bottom_left : {
x : ((width/100)*7.5),
y : ((height/100)*92.5)
},
left : {
x : 0,
y : ((height/100)*50)
},
top_left : {
x : ((width/100)*7.5),
y : ((height/100)*7.5)
}
}
}
img.onload = function() {
shape.beginPath(shape.node.top_left)
shape.createCurve(shape.curve.top, shape.node.top_right);
shape.createCurve(shape.curve.top_right, shape.node.right_top);
shape.createCurve(shape.curve.right, shape.node.right_bottom);
shape.createCurve(shape.curve.bottom_right, shape.node.bottom_right);
shape.createCurve(shape.curve.bottom, shape.node.bottom_left);
shape.createCurve(shape.curve.bottom_left, shape.node.left_bottom);
shape.createCurve(shape.curve.left, shape.node.left_top);
shape.createCurve(shape.curve.top_left, shape.node.top_left);
image.closePath();
image.clip();
image.drawImage(img, 0, 0, width, height);
image.restore();
}
img.src = "http://goo.gl/pC8iIF";
</script>
Continue reading →
As of Maven 2.0.9 a new feature was added to Maven called dependency mediation. Dependency mediation is the technique used by Maven to resolve your project dependencies in the specific case when a dependency occurs multiple times in your dependency tree. Usually this occurs on transitive dependencies linked through the dependencies of your project. In these cases mediation will be performed using the nearest win-strategy. In short this strategy means that Maven will use the version declared in the pom.xml that is closest to your project pom.xml. Hence, no in-depth intelligence is used to resolve the dependency conflict. Actually, I can't really think of a conflict resolve strategy that would really solve this problem. Any strategy I can think of has the hazard of linking incompatible dependencies in to your project. Using Maven version ranges can ofcourse resolve compatibility between artifacts, but this also requires you to establish a compatibility matrix of your dependencies. A pretty tedious task if you ask me. Now this whole mediation feature might sound like a very undesirable feature, but it's not! With this feature you can now at least be made aware of any dependency conflicts in your project dependencies. When you build your project using the -X switch, Maven will output all mediations (and a lot more) that have been performed. Now, wouldn't it be cool if there was a maven-plugin to detect mediation? JDriven took the liberty of extending Apache's dependency plugin with such a feature and share it with you. The goal used to detect mediation is mvn dependency:mediation. Additionally two interesting parameters can be added: 1) -DdisallowMediation=false 2) -DinspectArtifactId={some artifactId} As the name already implies, disallowMediation determines whether or not mediation is allowed. When allowed, the plugin will only warn about mediation being performed on dependencies. Very usefull when combined with for instance Jenkins' ${IS_M2RELEASEBUILD} variable to disallow mediation for release builds, yet allowing it for snapshot builds. The inspectArtifactId parameter is much like goal dependency:tree -Dverbose=true, it will check mediation and print dependency information regarding the artifact having id {some artifactId}. In your pom.xml your can add additional configuration to filter which dependencies must be checked on mediation:
com.jdriven.maven.plugins
maven-dependency-plugin
2.8.1
com.jdriven:\*
Continue reading →
