you also could use t:saveState on your backing bean instead of putting it into the session ;-)
Rick Gruber-Riemer wrote: > 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?
