Browsing around the Q&A on JavaRanch.com I see a lot of the same questions when it comes to web frameworks. To paraphrase:

"Which web framework should I choose and why?"

I and others often respond with the typical canned answer. This answer comes in many flavors; "There is no golden hammer", "We can't answer without the context of your project", "Every project requires its own investigation to answer this question", etc, etc. The meaning of those answers is all the same, however. But is it true?

The last 3 projects I've worked on I really pushed for, and was able to use, Stripes. I really like Stripes and since I am not a "full stack" person I generally like to pick and choose each portion of my solution puzzle. Stripes is my go to web MVC piece of that puzzle. And I honestly can't recall that during the discovery phase of any of these projects I honestly considered anything else. (on my current project we did discuss Symfony vs Stripes but that is more of a language debate than framework debate). Is that a mistake? I don't think so. If you use, like, and favor Wicket do you really consider something like Struts 2 or Spring MVC when you are getting ready to start a new project? I'd be willing to bet you don't.

I think we all like to think that we are open minded about this sort of thing but the passion on blogs and forums (or flame wars if you prefer) really prove otherwise. Most developers think their tool box contains the golden hammer(s).

What do you think?

Update It has been brought to my attention that I have repeated some information contained on the Flex homepage in my ramblings here. I just wanted to point out that is wasn't intentional and I was not trying to plagiarize. But the fact that my sentiments reflect that of Adobe's is pure coincidence.

In my JavaFX Too Late... entry I said the following about Flex.

But where are the Flex driven applications? Where are the AIR applications? I'm sure some of you will drop a few links in the comments. But considering the number of blogs I read the the number of different kinds of websites I visit not only for fun but also to try and keep abreast of the latest and greatest going on in development, I have yet to run across a Flex driven web site.

James Ward politely pointed out some links where I could see more Flex in action (not the book). After spending some time doing this I started doing a bit of home brewing of my own with Flex. Here are a few reasons why Flex looks appealing to me (in no particular order).

I don't have to give up Java - Right off the bat this is huge for me. I've invested much of my career in Java and for me to move to something entirely away from Java, well, that something would have to be phenomenal. With flex I can leverage all my Java skills on the server while providing a really nice UI on the client. And I can even use my Java skills while writing ActionScript because they are similar languages.

Useful out of the box - The core set of components are useful enough in themselves for most basic applications. And its not like Swing components where they just do the most basic trivial thing. Flex stock components do what typical users want them to do without any extra work from the developer, for the most part. This segues into my next point pretty well.

Less code more goodiness - Look, I don't mind coding. I am a developer. Writing code is fun. But I'd rather write code that doesn't already exists. I think we all would. Getting flex components up and running requires, generally, very little code to do most common things.

Browser issues - I love JQuery. It solves so many problems when it comes to JavaScript. But it doesn't solve all of them. I spend more time debugging browser issues than anything else. And its not just JavaScript. It's CSS also. I have style-ie.css files. Enough said. With Flex those issues disappear because no matter what browser you use it is Flash (as long as you can live with the 'it is Flash' part).

Open Source - Flex 3 is open source. All of it. Adobe is moving in a good direction to make Flex as viable as it can be and as attractive to developers as they can.

So these are my current reasons for digging deeper into Flex. What I plan to do next is try and come up with a list of reasons not to use Flex. Reasons other than not being the right tool for a specific task. I still believe strongly in choosing the right tool. To choose the right tool you need as much information as possible. The only way for me is to write code so that is what I need to do.

I am still looking for the defacto place to ask specific Flex questions. I've been looking over the official Adobe Flex forums as well as the Yahoo Flex+Java UG. I'm not sure where the real experts hang out. I know for Java it's JavaRanch. Maybe JavaRanch needs a Flex department.

I got a surprise in my inbox the other day. Manning released the final ebook version of Wicket In Action. I was surprised because it had been a while since I got an update from Manning that I honestly forgot I had purchased the book. Normally I read a book a couple of times and then write a review. I'm trying something new with the Wicket book. I'm going to write a review of each chapter and then a summary review. So this is my review of Chapter 1 which is also available as a free download from the Wicket In Action web site at Manning.

Chapter 1 starts off like most tech books starting with a brief history of Wicket, the problems it solves, and ends with an introduction to developing with the Wicket framework. The author explains things well and throws in a bit of humor here and there. No true tech book is complete without a reference to Star Wars and sure enough it is in there. It helps that your framework is named after a fuzzy little ewok. Or is it a piece of equipment used in Cricket? I guess you'll need to read it to find out.

The author does a great job getting you excited for the rest of the book. Screenshots are shown of an existing Wicket application and it looks nice. How difficult it is to get to that point using Wicket remains to be seen, however. Simple code snippets of Wicket java and markup keep the reader interested in what is to come. Overall, Chapter 1 is great lead off point.

The only problem I had was example code was given but no clear direction on how to execute that code locally was provided. There are no step by step instructions on downloading Wicket, setting up the web.xml, etc. This could be in a later chapter or an appendix but I am not hopeful. A quick search on the PDF for 'web.xml' only returned a snippet for getting Spring working.

Check back for my review of Chapter 2.

Yesterday I was going through this SpringRCP Tutorial. It is looking quite promising. My only real problem is that the only plugin available is for Netbeans and I use IntelliJ's IDEA for all my development. So I set out to see what it would take to get the very basic SimpleApp working from IDEA.

It wasn't too bad really. I've made the SimpleApp source with IDEA project files available here. To keep the file size down I didn't include the JAR files but here is a list of all the ones you need just to get the SimpleApp to run:



You can get all these JAR files plus everything else you need for full SpringRCP development from the SpringRCP Project Site.

What you don't get is all the plugin features that Netbeans provides. Hopefully as SpringRCP becomes more mature and if it is successful someone will do me a solid and provide a plugin for IDEA.

Last week I wrote an entry on implementing application wide hotkeys or global hotkeys. I mentioned writing a new article on how I implemented IntelliJ's Goto Class though I think calling it the same as Eclipse's Open Resource is a better name for my application since I'm not dealing with classes at all.

Read more...