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

[Rick Gruber-Riemer <ri...@vanosten.net>]

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?

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

[Werner Punz <we...@gmx.at>]

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?