With traditional Action MVC frameworks (Struts), you have a specific set of scopes to store state in over transactions: request, session, and application. Often, while developing applications with Action MVC frameworks, you have to make a decision to store objects/state in the request or the session. There can be consequences to the the performance of your application in either case.
In one my last blogs on the concepts behind Avatar involved trying to gain performance via AJAX by partially processing a UIComponent tree in JSF.
With complex enterprise systems, we often times find ourselves with lots of 'flags' or 'types' within our database tables. Utilizing Hibernate's UserType facility, we can handle these types in such a way that will carry extra behavior and information within your domain models.
A little over a year ago, the JavaServer Faces specification caught my interest. I've always considered myself a 'do it yourself' programmer and went as far as to start my own implementation of the JavaServer Faces specification.
At this point, I would like to show you some of the JSP pages we have in our application, but I'm sure there's a clause somewhere in my contract that says otherwise.
There's been some chatter online about using JSF-specific annotations to drive application coordination. But, really it's your enterprise business model (EJB 3) that should be at the wheel.
In my last blog entry, I 'kind of' complained about how JSF's component model was maintained and all the overhead involved. Really, I can't think of it as overhead, because it is tremendously richer in what it can do than other component frameworks.
I've been racking my brain lately, tossing around ideas. I've been working tons with Facelets technology with trying to push JSF into new directions, but it still sits on top of JSF. Not that there's anything wrong with what JSF does, it's really rich, almost too rich.
Ruby on Rails: love it or hate it, but it does have a lot of fresh ideas.
Let me give you a hypothetical project that involves two groups. One group develops a thin client, that is delivered over the web. This thin client works in conjunction with a fat, installed client that the other group developed. The first beta hits, both groups have a couple kinks to work out.