Friday, February 19, 2010
Interesting Java tidbit
If you pass a number in String form, padded with spaces, like " 89.99 " for example, to Double.parseDouble(), no exceptions will be thrown. If you pass the same number to Integer.parseInt(), a NumberFormatException will be thrown.
Wednesday, January 13, 2010
Spring Lessons
In the past few days, the veils obstructing a couple rules-of-thumb have slowly melted away:
1. Don't use model objects as form backing objects. Use simple value objects instead. This adds an extra layer, but eliminates complications. This is especially true in Spring WebFlow (2.0.7) which does not instrument the "open session in view" pattern, unlike Spring MVC which odes.
2. Make sure your value object fields are Strings as much as possible. If a field represents a number, you can convert it later. Doing this avoids the need to configure pretty binding error messages for the user, when, for example, the user enters characters into a form field which binds to an Integer field in the value object.
Added (2-19-2010): More generally, if you are discontinuing the use of a database column that has been in existence for a long time, do not delete the column, because removing all mentions of that column from all the code can prove to be quite hairy.
1. Don't use model objects as form backing objects. Use simple value objects instead. This adds an extra layer, but eliminates complications. This is especially true in Spring WebFlow (2.0.7) which does not instrument the "open session in view" pattern, unlike Spring MVC which odes.
2. Make sure your value object fields are Strings as much as possible. If a field represents a number, you can convert it later. Doing this avoids the need to configure pretty binding error messages for the user, when, for example, the user enters characters into a form field which binds to an Integer field in the value object.
Added (2-19-2010): More generally, if you are discontinuing the use of a database column that has been in existence for a long time, do not delete the column, because removing all mentions of that column from all the code can prove to be quite hairy.
Tuesday, January 5, 2010
Is Spring WebFlow worth the trouble?
This post begs to be fleshed out, and I hope to return and do so. The question is: Is Spring WebFlow really worth all the trouble? It's a nice abstraction, but does it save time? I'm not so sure. For one, there's no OpenSessionInViewFilter pattern in WebFlow.
A work colleague pointed out that WebFlow saves you from writing a lot of controller code for transitioning from screen to screen. Also, it aims to solve the "back button" problem and related issues.
A work colleague pointed out that WebFlow saves you from writing a lot of controller code for transitioning from screen to screen. Also, it aims to solve the "back button" problem and related issues.
Monday, January 4, 2010
Invoke window.open() from a link
Jennifer Madden does a great job explaining how to invoke JavaScript's window.open() method from a link, avoiding some common pitfalls. Thanks Jennifer!
Sunday, December 27, 2009
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.
Thursday, December 24, 2009
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.
Wednesday, December 16, 2009
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.
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.
Subscribe to:
Posts (Atom)