Design question: how best to pass query from search-form to result-page

[Rick Gruber-Riemer]

Hi I would like to know what the best practice is to pass a query from a "search-"form to a results page. With this a mean page A with some form elements to search for records in a database and page B showning a table of results with all matches. I can come up with the following 5 alternatives: [A]: A.jsp and B.jsp refer to the same Backing Bean, which has session scope. So when B.jsp is called and the table rendered, the Backing Bean has directly access to the search form fields and can use these to submit a query in a DAO. [B]: A.jsp and B.jsp have Backing Beans A.java and B.java in request scope. A.java puts the form elements within its action method into a Map, which is stored in either the request or the session. B.java reads the Map from either session or request and uses them to submit a query in a DAO. [C]: pages and beans like [B]. But A.java's action method actually makes query in DAO and then puts the result in session or request. [D]: This time in A.java's action method FacesContext is used to get an instance of B.java and set the form parameters with getters/setters, such that in the render phase of b.jsp a query can be made against a DAO. [E]: In A.java's action method submit the form parameters to a DAO method, which returns a query string. This is then set into a session parameter. In B.java get the query string from the session parameter and use it then to submit a query in the DAO. The beauty of this would be that the concrete DAO implementation would generate the relevant query, such that it would be transparent for the Backing Bean and a Business Delegat whether we use a Hibernate implementation or plain SQL or JDO ... And the query string does not use a lot of memory in the session :-). Plus a "select count(*)" in the DAO already when getting the query string in A.java could reveal, whether the user has to be more precice as the query would return to many records (configurable). Pros/cons: [A]: Positive: easy to implement. Negative: session scope and results potentially hanging around in session (e.g. for simple pager). [B]: Positive: request scope. Negative: as with [A] the Map gets some logic with field names that need to be maintained. [C]: Positive: easy to implement. Negative: As with [A] there can be problems if using request parameters in portlets (as far as I know). Results can be big and somehow should be nullified in session as soon as pointer is set in B.java. [D]: Negative: not really an improvement over [A]; I do not like to play with BackingBeans in FacesContext (-> session vs. request scope?) [E]: Positive: I just like it ;-) Any comments?