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.