By using good frameworks like iBATIS (which has great support for pagination and dynamic queries) and design patterns pertinent to the requirement, the code in the layers you can be kept to a minimum. The web application at workeffort.dev.java.net does all kinds of pagination, ordering sorting etc from the database. The methods for pagination in the struts actions is a few lines and the service layer method call is a one liner. There is no code bloat if you take the time to design the different layers appropriately.
Applications of reasonable sizes generally deal with queries that return a whole bunch of records (as developers we would like to limit the records returned, unfortunately this is dictated by the users, and they want to query by all kinds of different criteria and rightfully so) and if these records are stuck in the users session, the application is not going to scale. ----- Original Message ----- From: "Bill Schneider" <[EMAIL PROTECTED]> To: user@struts.apache.org Subject: Re: Displaying mulitpage results Date: Mon, 21 Feb 2005 09:16:16 -0500 > > > Check out the datagrid library at > > http://jakarta.apache.org/taglibs/sandbox/doc/datagrid-doc/intro.html > > > > If all you are looking for is pagination, sorting and ordering > > from the database this is a good fit. It does not have all the > > bells and whistles displaytag has, but is a simple and clean > > implementation. > > > > The biggest issue I have with the stock displaytag is, you have > > to stick the whole query result somewhere (generally in the users > > session) to do pagination. A very bad idea in my opinion. > > It's not a bad idea, it's a tradeoff: if you want native DB > pagination (e.g., limit/offset in PostgreSQL, TOP xx in SQL Server, > etc.) you either have to couple your UI components directly to the > database, or you have to handle pagination at each and every layer > in a multi-tier design (Struts Actions, business logic/session > beans, DAOs/entity home interfaces, etc.) Neither choice is > particularly appealing for the common case. > > My feeling is that, if you can't afford to pull all the results > into memory at once, pagination probably is not the right UI design > anyway. How meaningful is it to allow the user to jump to page 87 > of 439? You should look at pagination strictly as a UI construct, > to optimize *client* side performance rather than server-side > (i.e., to avoid scrolling and downloading long HTML over a possibly > slow dialup link). Then, in exceptional cases, you can always break > abstraction and couple your UI directly to the DB (with JSTL sql > tags, for instance) for server-side performance tuning when you > really need it. > > -- Bill > -- Bill Schneider > Chief Architect > > Vecna Technologies, Inc. > 5004 Lehigh Road, Suite B > College Park, MD 20740 > [EMAIL PROTECTED] > t: 301-864-7594 > f: 301-699-3180 > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] Antony Joseph Available for consulting http://www.logicden.com -- _______________________________________________ Find what you are looking for with the Lycos Yellow Pages http://r.lycos.com/r/yp_emailfooter/http://yellowpages.lycos.com/default.asp?SRC=lycos10 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
