I was working a JSF project which, as all JSF projects do, needed a bunch of validators. It was getting a little bit messy having a lot of boilerplate code and validation algorithms that couldn’t be reused. So I decided to streamline the code and usage of validators in JSF in general, in combination with dealing with validation messages optionally using resource bundles.
The solution I’m suggesting isn’t rocket science, but it serves its purpose in keeping everything maintainable, understandable and easy to work with.
Let me know what you think.
[ Download all sources ] read on
Here’s a quick tip I found very useful in Windows, involving Eclipse template system and the @Author annotation.
Say you are working under some kind of account, for example some assigned number combination which you use to log into Windows or something. Mine recently was AA170738. Now say you are editing Java classes in Eclipse and generating comments with Eclipse. You might end up with something like this:
| /** * @author AA170738 * */ |
I Found this very annoying since it happened to me for every class I introduced and templates are supposed to save time. You could ofcourse turn it off entirely, Preferences->Java->Editor->Templates->uncheck @author, but I just wanted it fixed the right way.
Turns out Eclipse simply reads out the Java system property user.name. All we need to do then is boot Eclipse with an explicit system property. Like so…
eclipse.exe -vmargs -Duser.name=”John Doe”
Just change that in your shortcut and you’re set.
| /** * @author John Doe * */ |
Some time ago I came across a very interesting article by Robert C. Martin (1996 column in pdf) about how packages are supposed to be made up and how it helps building a release, debug and shared-workload strategy. I don’t think it all applies to modern package management, especially for web applications, but it is an interesting perspective that deserves some attention.
granularity.pdf (original source offline: www.objectmentor.com/publications/granularity.pdf)
My summary of his article (as I understood all of it):
read on
Sometimes it is best to know forehand some of the more obscure features and limitations of a software product, before diving in. One such obscure limitation is that of the infamous Obliterate feature of the Version Control software, Subversion, that people only learn of when they discover it is not there. Will you need it? Most likely yes, at some point. Especially if you are dealing with a large codebase, you will want to be wary of Subversion, however great its existing feature are. Read on.
read on
Direct Web Remoting, or DWR in short, is a technology that helps you ease the development of javascript based applications using a Java server. What it does is simply sit in between your javascript and your java classes and acts as marshaller for method calls from javascript to Java. In a nutshell: DWR provides Remote Procedure Calls for javascript and is a great library for use in Ajax enabled webapplications.
This isn’t yet another blogpost about what DWR exactly is or why it is so cool; the objective of my post today is to simply set up a quick example of how to work with it. A quick tutorial if you will. I’m the kind of guy that likes many examples and diagrams and whatnot to take apart and learn from, so here’s my contribution to the ‘code by example’ paradigm. If you want to know more about DWR before actually trying to use it, I suggest you check out the DWR homepage.
read on