Seam conversations have certain rules that you need to be aware of when using them. This article came about because for the last couple of years, the same questions have been asked on the Seam forums regarding conversations. It is also a couple of issues that cropped up while I was working on the Seam vs. Spring Web Flow articles. Some of the problems are uncannily similar with similar solutions, so parts of this series may be of interest to non-Seam users. Additionally, it seems like a lot of this stuff will also apply to the conversational pieces of JSR 299 – Contexts and Dependency Injection which will be a part of JEE 6.
Read the rest of this entry »
Posts Tagged spring
Conversational Pitfalls
Nov 17
I’m looking at starting a new project and once again find myself choosing between frameworks. Having spent some time evaluating different ones I wrote up some notes to share and get some feedback that might alter my thoughts or opinions. Here’s the criteria I’m using to choose a framework in no particular order.
Read the rest of this entry »
In the fifth part of this four part series, I decided to give a non-conversational framework a try and implemented the same application with Wicket which is a semi-stateless framework.
(update : If you have already read the previous version only chapter 5 is new and has the Wicket example and final comparison.)
Enjoy,
I recently had to start another project using Spring Web Flow and found myself banging my head against a brick wall to get the web flow stuff set up and to request the page properly. As a result, I decided to write up my results as a quick how-to for other developers should they find themselves in the same situation and also as a reference for myself the next time I need to start a Spring Web Flow project using Spring Faces from scratch.This article is meant more of a “here’s-how” as opposed to a “how-to” or an “explain-why” so we’ll move at a quick pace with little explanation.
The last installment is finally ready. After many a re-write and consideration of all the issues to come to a fair conclusion, especially as new versions were coming out and new features are being added, I’m finally able to publish it. Framework Comparisons – are they ever completed? Anyways, here it is in all it’s ….well, it’s here. Enjoy.
I know it has been a while since I pushed out my last piece on Spring Web Flow vs Seam, but I am still trying to get it ready. With Christmas, software releases at work leading to a hectic work schedule, and other stuff I have limited time. Furthermore, I am still re-writing parts of it, and I end up digressing into related info that is not central to the piece. Also, I am still having difficulty accurately writing up the final conclusion in a fair, and informed manner.
However, hopefully, I will get it completed in the next week here and I can get it released. I may also have some additional material for blog posts.
This is the third of a four part series comparing Seam vs Spring Web Flow (SWF),and looks at the Seam implementation of the sample application.
(Updated 1/19/2009 : Changed links to point to the whole set of articles)
HTML
Single Page HTML
PDF
This is the second of a four part series comparing Seam and Spring Web Flow (SWF),and looks at the Spring implementation of the sample application that we discussed in part 1. In a day or so I will have the piece that looks at writing the application using Seam.
(Updated 1/19/2009 : Changed links to point to the whole set of articles)
HTML
Single Page HTML
PDF
This is the first of a four part series comparing Seam and Spring Web Flow (SWF) from different aspects, primarily with respect to building web based CRUD applications. It includes writing a simple but fairly complete application using both frameworks and then comparing the differences between the Seam and the SWF implementation.
This first part starts by taking a look at the two frameworks, where they come from and briefly, how they are used.
(Updated 1/19/2009 : Changed links to point to the whole set of articles)
HTML
Single Page HTML
PDF
In this post I talked about how the Java standards are important to ensuring java has a long and fruitful life. This post references Spring as an example but was written before the fallout from the Spring licensing issues. This fallout tends to back up the argument that standards are important, although since there were no standards at the time for Spring to follow, it is not a totally valid position.
Over the years, many people have been knocked for claiming that Spring is a proprietary framework. How can it be when it is open source would often be the argument. Proprietary in its literal sense means that it has one owner or controller which is true for Spring for the most part. A less formal definition when discussing programming, Java in particular, is that it does not follow any open standards. Spring broke a lot of new ground which in many cases, meant that there were no standards or only bad standards to follow. However, a number of developers also bought into using other Spring features like the Templates to aid them in their development.
Now that Spring has penetrated developers code to a large degree, vendor lock in was in place for many companies with large spring based projects and Rod and Co turned off the free beer once everyone was hooked. Again, it’s their business, their platform, and they can do with it as they like.
However, if the Java platform had a set of good standards for defining framework functions, then nobody would seriously bother with a non-standard framework, and nobody would be able to shut off the tap because they could be replaced in an instant by an alternative implementation of the standard. Again, this reinforces the need for good standards (like EJB3.1 appears to be) and also for timely updates to the standards.
