tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erik Hatcher <e...@ehatchersolutions.com>
Subject Re: some notes
Date Mon, 08 Dec 2003 23:42:44 GMT
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 ("<name>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.

>>      <component id="nameColumn" type="Block"/>
> 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.


To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org

View raw message