Jeff Storey

Ranch Hand
+ Follow
since Apr 07, 2007
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
2
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Jeff Storey

Several years later, I came across this post I had forgotten about. I realized that I was in fact wrong on the behavior of the island of isolation. Just wanted to clarify here in case anyone else stumbles across this.
11 years ago
Thanks Andres. I'll be sure to give it a go. Appreciate your contributions to the forum!
12 years ago
Thanks, Andres. I'm excited about trying out Griffon.

One thing that still concerns me about migrating to Griffon is that I'm wondering if it will be possible to migrate over gradually, or do I need to basically stop everything and do a big change all at once? Your thoughts?

Thanks,
Jeff
12 years ago
Andres & Danno,

I work on a swing application, and we currently use a lot of groovy for the back end. We use some groovy on the front end, especially the SwingBuilder, but much of the core UI code is written in pure Java. The application is pretty small right now (~50k sloc for UI and backend combined). Would you recommend trying to migrate the app to the Griffon framework as it grows to help manage it? Or might it be too difficult to migrate and existing app such as this?

Thanks,
Jeff
12 years ago
Excellent, thanks Christian.
Does js-test-driver provide a way to mock this behavior? Or would I need to look into another framework for that?

thanks,
Jeff
Christian,

In your book, do you cover examples on how to capture javascript popups such as alert dialogs and how to test that they did/did not appear?

thanks,
Jeff
You could also use the EasyMock class extensions to make your mock an instanceof SqlMapClientImpl (since I assume SqlMapClientImpl implements the SqlMapClient interface).
13 years ago
Typically your persistence operations will occur in the model, yes. The model should be talking with a generic persistence interface though, not specifically with SQL or file/IO, since the persistence mechanism could change.
13 years ago
Hey Paul,

I appreciate the insight. I actively practice TDD and I agree that it certainly reduces the amount I use the debugger, and that has really helped at the unit level. The place I find myself using the debugger more frequently is when I'm doing any manual integration and acceptance testing and something goes wrong. Also when I'm using 3rd party code (when I have the source), it's useful to be able to step through. Not to say that you can't do that with groovy code, but because of all the "magic" groovy does with the code, sometimes it's just a little more tedious and I find myself at times reverting to good old println (and in groovy, it's even easier since you don't need the whole System.out.println). Either way, I still find the benefits of groovy outweighing this issue.

Thanks,
Jeff
14 years ago
Yep! I wonder if they could have a debugging feature that skips the groovy code ... maybe I'll ping the developers on that one too, but I'm certainly open to other suggestions.
14 years ago
Hi Paul (and everyone else in the forum),
This may be more of a groovy forums question, but do you have any tips for debugging groovy code in an IDE (I use Eclipse)? Groovy adds so many layers of calls that it can be really tedious to step through the code, and it's a pain to put a breakpoint at every java line I'm interested in stopping at.

thanks,
Jeff
14 years ago
Great article references here, David. I want to go back to a post earlier on where you mention the idea of using injected singletons (I wrote blog post on that a few months ago http://jeffastorey.blogspot.com/2009/08/spring-managed-singletons-for.html). It's actually an excellent point, not to be overlooked as an aside. Allowing a container (such as Spring) to manage your singletons is useful for a number of reasons:

1. Classes are not asking for objects with tons of references to getInstance, rather they are given a reference. An object should be concerned with its own behavior and not about how ti gets the objects.

2. It makes objects much more testable. Mocking singletons is very difficult and may discourage test writing.

3. If later on down the line you realize that something that was a singleton shouldn't have been, or vice versa, it's much easier to change that using injected singletons.

On a side node, using a practice like test driven development will really help discourage singletons. When you write the test first, it's unlikely you'll write the test around singletons.

That's my input for what it's worth.

Jeff
14 years ago
getIterator would typically be used to return an Iterator that the user can use to walk the list in order and see all of the elements. Usage of it might look like


The key is that the iterator needs to return the items in order.

Jeff
14 years ago
I wonder if the hard kill is causing the port to stay active and not always shutting down properly. When it happens again, just run netstat to see what's using the port.
14 years ago