Return-Path: Delivered-To: apmail-jakarta-struts-user-archive@apache.org Received: (qmail 26115 invoked from network); 5 Nov 2002 21:31:41 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 5 Nov 2002 21:31:41 -0000 Received: (qmail 19464 invoked by uid 97); 5 Nov 2002 21:31:35 -0000 Delivered-To: qmlist-jakarta-archive-struts-user@jakarta.apache.org Received: (qmail 19409 invoked by uid 97); 5 Nov 2002 21:31:34 -0000 Mailing-List: contact struts-user-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Struts Users Mailing List" Reply-To: "Struts Users Mailing List" Delivered-To: mailing list struts-user@jakarta.apache.org Received: (qmail 19349 invoked by uid 98); 5 Nov 2002 21:31:33 -0000 X-Antivirus: nagoya (v4218 created Aug 14 2002) Date: Tue, 05 Nov 2002 16:32:32 -0600 From: Eddie Bush Subject: Re: Continuous datastream from server to client To: Struts Users Mailing List Message-id: <3DC84700.9040904@swbell.net> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 References: <2C64934959BCE94AACCD2068692688A2B0DD@stone01.webstone.local> X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N If you're using OJB, you have access to the Query interface. That particular interface is *very* useful. You can specify a beginning index and an ending index. With minimal coding on your part, it's super-simple to have something that will do pagination. I went so far as to give my DAOs which may return collections another method with a signature that allows me to specify a page number and a page size - have that method determine the start/end index (very simple logic - encapsulate it somewhere [like your base DAO] and just invoke it), execute the query, and return me the collection. Very easy to do. - search ojb-user - examine the Query interface (org.apache.ojb.broker.query package, if memory serves). I still say generate it as a CSV download. I can't imagine why you couldn't generate the CSV dynamically. I know I don't determine a content-length for dynamic pages I build. You will need to set the content-type though (text/??? - no clue what the mime type for CSV is). Plus, generating large dynamic tables can be ... problematic. Reinhard Dunst wrote: >Hi, thanks for answer. >I'm using OJB for database access but for the moment without proxy. >I think the user is responsible to print only lists of acceptable lenght. >But if he >wants to print a long list he should do, across ?? pages and not page by >page. >When I saw, that I could run into memory problems, my next idea was to use >the PrintWriter from HttpServletResponse, create html code and flush every >10th row. >But I never tried it. An other Idea is to create a PDF File in the >background. During creation I render a pagecounter on a seperate page and >when finished I create a link on output page, but thats my last option. > >So you think, there is no way to send data with undefined length from server >to the client? > >Reinhard > -- Eddie Bush -- To unsubscribe, e-mail: For additional commands, e-mail: