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.
Read Part 1
Seam versus Spring Web Flow part 2
Dzone have released a new cheat sheet for Seam users written by Jacob Orshalick. It covers a number of Seam areas such as :
It is available for viewing or download after the obligatory sign up (or log in if you are already a member) from the dzone refcardz zone.
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.
In this post about pagination with Seam entity queries, I outline a method to encapsulate the pagination mechanism in a facelet that internally uses hidden fields to hold the state. Alexander Rühl pointed out that Dan Allen in his book Seam In Action recommends avoiding hidden fields in favor of page parameters lest they become a tangled mess. It’s a fair point, and one that probably deserves a better answer than a brief post comment.
For the most part Dan is correct, but let’s consider a form with 4 or 5 tabs on it that show the details for a master entity. Each paginator requires 3 parameters (order, order ascending, and first result) and 4 if you include a page size parameter . That’s 15 or 20 parameters you have to write for the page, each with their own unique names making a rather lengthy and odd looking URL, a URL which is only bookmarkable as long as you are using GET requests since form posts only propagate the parameters internally (not in the URL).
The best solution (although it doesn’t work) would be to put the EntityQuery into Page scope so everything is remembered with or without a conversation and without hidden fields, but Entity Queries don’t work in page scope.
Dan’s reference and the one in the Seam documentation relates to a simple search page where you might want to put the search criteria and the current results page in the link to create a bookmarkable URL. That’s a fine solution, and an appropriate one where the parameters serve a purpose.
In this case I don’t think the hidden fields become a tangled mess because they are not visible (no pun intended), they are encapsulated in the facelet that handles the pagination. I can include the pagination facelet without having to define the page parameters. The alternative is to include the same pagination facelet, passing it the same entity query as a parameter and then going and writing 3 or 4 parameters for each grid. By reusing the hidden fields, I save myself 3 lines of parameter definition per grid and I have a solution that is less prone to errors based on mis-typed parameters. Also, if I change the source of the data from one query to another, I just need to change the parameter to the paginator facelet whereas I would need to change all the defined page parameters for that query.
Regardless, I think you can use page parameters instead of hidden fields without a problem, but I don’t think there is any advantage, nor does it remove any disadvantages from using hidden fields, and it requires more code to write/test/maintain.
One common code pattern that we find ourselves writing time and again is the ability to display tables which are paginated and sortable. Ideally, this is something we should try and be able to re-use throughout our application.
Let’s start by looking at where we are now with the features that come with Seam out of the box. In particular, we will be looking at the dataScroller component and the EntityQuery object. (more…)
One of the problems faced by Seam users is the disconnect between the session scoped entity instances and using them in more local scopes. A good example is a session scoped User instance that is loaded when the user logs in and is outjected into the session scope. This user instance is available for the duration of the users session.
This user entity is great for displaying who the logged in user is and other information. The problem comes when you
need to use that User entity in conjunction with other entities that are managed by the locally scoped entity manager. If an entity has a property that references the current user (such as a createdBy property), then it might seem obvious to assign the User variable value to that value. However, the User is unmanaged by the entity manager for that conversation and will raise errors when you try and save the entity referencing the unmanaged User.
We could make the instance managed before we save it or assign it to the property, but this is a session scoped instance, and it could be shared among multiple conversations. We may want to compare the instances at different times in the same conversation which will break if it has been altered by another conversation. Also, we don’t want to
have to write code to handle each property assignment or saving each entity type. (more…)
