tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mindbridge" <mindbridge...@yahoo.com>
Subject Re: some notes
Date Mon, 08 Dec 2003 19:35:58 GMT
Hi,

> What does the "Language:displayLanguage" syntax mean?

There are several column parameters that need to be defined, I think:
- column id
- display name
- ognl expression to get the column data

I've been thinking of the following syntax (using either should work):
name
name:ognlExpression
name:displayName:ognlExpression

If a particular parameter is missing, the name is taken instead.
Also, if the display name is missing, it is translated using the component's
translation mechanism. If the translation fails, the name is used.

Prepending ! would turn off sorting.

Finally, since these parameters do not fully define a column (there is
comparator, custom renderers, etc), the following syntax should also work:
=<ognl expression to return an object of type ITableColumn>

Also, the 'columns' parameter of Table would accept not only a String
(described above), but an array of columns or a column model.

Sounds complex perhaps, but I think it is pretty easy to use (and implement)
:)

>      <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.

> The main concerns I
> have with my version is how it deals with the session state and memory
> usage - I'm not convinced it'll hold up well when there is ton of data.

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?

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.

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:

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.

-mb

----- Original Message ----- 
From: "Erik Hatcher" <erik@ehatchersolutions.com>
To: "Tapestry development" <tapestry-dev@jakarta.apache.org>
Sent: Saturday, December 06, 2003 1:20 PM
Subject: Re: some notes


> On Saturday, December 6, 2003, at 05:20  AM, Mindbridge wrote:
> > 1. New beta
> > Since the last beta there have been a lot of bugs fixed (around 30),
> > there are build process updates, there is updated documentation.
> > Perhaps it makes sense to have another beta soon, say end of the
> > coming week?
>
> +1
>
> although if you're referring to my junit/build.xml changes, those are
> inconsequential (I added two targets that stand alone, not affecting
> any thing else).
>
> > 3. Some minor Table changes
> > The Table component allows for a lot of things, but it is not that
> > easy to use, unfortunately. I would like to make some very minor
> > changes that will allow it to behave very much like the Foreach
> > component. E.g. displaying all locales in a web page would look
> > something like this:
> >
> > <table jwcid="contrib:Table"
> > source="ognl:@java.util.Locale@availableLocales"
> > columns="locale:toString(), ISO3Language, ISO3Country,
> > Language:displayLanguage, Country:displayCountry,
> > Variant:displayVariant"/>
> >
> > This only requires adding a simple wrap -- the functionality is all
> > there. Together with the column proposed by Erik, this will likely
 > decrease significantly the problems people are having.
>
> I'm happy to contribute what I've done with my wrapper around
> contrib:Table, although I'm not convinced it is "done" and will
> probably need more work.
>
> Your proposed bindings are very similar.  Here is a representative
> usage of my BeanTable:
>
>      <component id="tableView" type="BeanTable">
>          <binding name="data" expression="corporations"/>
>          <static-binding name="columns"
> value="name,industry,city,state,country"/>
>      </component>
>
> What does the "Language:displayLanguage" syntax mean?
>
> BeanTable looks for a block called <columnName>Block, like this:
>
>      <component id="nameColumn" type="Block"/>
>
> If found, it uses that block for rendering the column cells, otherwise
> it uses the OGNL expression toString rendering.  The main concerns I
> have with my version is how it deals with the session state and memory
> usage - I'm not convinced it'll hold up well when there is ton of data.
>
> Erik
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org


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


Mime
View raw message