Return-Path: Delivered-To: apmail-jakarta-tapestry-dev-archive@www.apache.org Received: (qmail 66878 invoked from network); 8 Dec 2003 23:42:58 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 8 Dec 2003 23:42:58 -0000 Received: (qmail 84908 invoked by uid 500); 8 Dec 2003 23:42:44 -0000 Delivered-To: apmail-jakarta-tapestry-dev-archive@jakarta.apache.org Received: (qmail 84891 invoked by uid 500); 8 Dec 2003 23:42:44 -0000 Mailing-List: contact tapestry-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Tapestry development" Reply-To: "Tapestry development" Delivered-To: mailing list tapestry-dev@jakarta.apache.org Received: (qmail 84878 invoked from network); 8 Dec 2003 23:42:44 -0000 Received: from unknown (HELO c000.snv.cp.net) (209.228.32.71) by daedalus.apache.org with SMTP; 8 Dec 2003 23:42:44 -0000 Received: (cpmta 5472 invoked from network); 8 Dec 2003 15:42:46 -0800 Received: from 24.51.109.181 (HELO ehatchersolutions.com) by smtp.hatcher.net (209.228.32.71) with SMTP; 8 Dec 2003 15:42:46 -0800 X-Sent: 8 Dec 2003 23:42:46 GMT Date: Mon, 8 Dec 2003 18:42:44 -0500 Subject: Re: some notes Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Erik Hatcher To: "Tapestry development" Content-Transfer-Encoding: 7bit In-Reply-To: <008101c3bdc2$81899b50$0900a8c0@mindbridge> Message-Id: <38854D50-29D8-11D8-8998-000393A564E6@ehatchersolutions.com> X-Mailer: Apple Mail (2.553) X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N On Monday, December 8, 2003, at 02:35 PM, Mindbridge wrote: > There are several column parameters that need to be defined, I think: > - column id > - display name > - ognl expression to get the column data I collapsed all of these into one basically. The string in our case represents either a named block ("Column") or an OGNL expression if no block exists matching it. It is also the key in resources for the display name, unique to the page it is in. We currently are not using any complex expressions, just non-dotted ones currently, so I haven't had to address it more generally. > Prepending ! would turn off sorting. Yup, good.... I thought of this also! Although currently all columns are sortable in our system. > Sounds complex perhaps, but I think it is pretty easy to use (and > implement) > :) Yes, I'm concerned with the complexity issue too. I don't think the comma-separated string with special notations is too complex, although I'm not too fond of it. Comma-separated lists in XML attributes just feels wrong to me. >> > > I fully agree that searching for a block with an id of nameColumn > would be > ideal. > The same mechanism could be used for the translation of the display > name -- > use 'nameColumn' as the key. We just used "name" as the key in this case. The "Column" suffix is just used to find a corresponding block. Whether this "convention" should be adopted or not I'm not sure. > My idea was that if this mechanism is used (source + columns > parameters, > rather than model), only the model state would be stored in the > session, and > the data would be extracted from 'source' at every request. That should > match the expectation of people, I believe. What do you think? Sounds good to me. Although our 'source' is only available when a form is submitted, and when selecting columns to sort or paging the data is stored in my wrapper component. It would be fairly drastic in our case to re-query to get the data just to do sorting and paging - although I suspect we'll have issues with this once large datasets are available. > This is still not the most efficient approach though, since if there is > sorting, it will be performed every time. The most efficient approach > is to > implement ITableModel so that the database performs the sorting for you > (using ORDER BY if possible) and you get only the data of the current > page > (using LIMIT/OFFSET, for example). This is what the SQL table model is > doing. This is not feasable for every situation, but should be way > faster > when there is lots of data. That is a clean way to do it. We have too many layers though, and going directly to the DB from the presentation is something that is not done in our architecture. It would make sense in a lot of cases, but we just don't do it from a purist point of view. > Btw, I've been wondering whether implementing ITableModel is not too > tricky > for some people and perhaps implementing a simplified interface would > not be > desirable, e.g: I can attest to there being nothing Simple* about the current table pieces :) (no offense, it's spectacular stuff, just took me a long time to figure out) > > public interface ISimplifiedTableModel { > // returns the number of all records > int getDataSize(); > // current page data. sortColumn can be null if there is no sorting > Iterator getData(int first, int size, ITableColumn sortColumn, > boolean > sortDirection); > } > > It is really trivial to make a wrapper converting this to ITableModel, > so no > pain on our part either. The simpler it can be made, the better. No question. Erik --------------------------------------------------------------------- To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org