T5: Some thoughts regarding the Grid component.

[Mike D Pilsbury <mi...@pekim.co.uk>]

I really like the Grid control. It's certainly very easy to generate a 
paged table with minimal effort. However there are several shortcomings 
that I've noticed.

1) Documentation
It's quite good, but doesn't quite go far enough. There is no mention of 
how to override cell rendering. I managed to work it out from the 
mailing list and T5 source.

2) Pager presentation
There needs to be a way of specifying next/previous/first/last page 
links, and their presentation.
There needs to be a means of controlling how many pages are listed and 
how they are elided.

Perhaps the option of completely custom pager presentation might be 
worth considered.

3) CSS classes
It is not possible to add your own class to the table/div. Overriding 
the style attributes of t-data-grid is fine, but doesn't always provide 
enough control. For example, if there is more than one grid on a page, 
and each requires it's own styling, it's not nice.

This is really a requirement of many controls. The component supplied 
classes will often need to be supplemented with the developers own class 
or classes. It can be worked around, by wrapping the grid in (yet) 
another div with a class, but that will quickly start making page and 
component templates messier than they need to be. Sometimes the page 
will naturally have a containing element that can fulfil this role, but 
often it won't do.

Maybe this isn't really a problem, and I realise that I might be alone 
in my concern.

4) Lazily loaded row data
Consider the case where the model supplied to the grid has several 
hundred objects, each minimally populated (perhaps with just a primary 
key). When the grid's row property setter is called, the object can be 
fully populated, perhaps by calling some service. So far so good. 
However it will typically be a lot more efficient to make a single call 
to a service to populate a batch of objects than making twenty or thirty 
calls for each model object in a page.

I'm not sure that this will be easy to work around, so maybe it'll just 
have to be lived with.



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

Re: T5: Some thoughts regarding the Grid component.

[Mike D Pilsbury <mi...@pekim.co.uk>]

I'd not really looked at GridDataSource properly. It does indeed do 
what's needed. Thanks.

I look forward to the refactoring that will facilitate a custom packaged 
grid.


Howard Lewis Ship wrote:
> On 2/27/07, Mike D Pilsbury <mi...@pekim.co.uk> wrote:
>> I really like the Grid control. It's certainly very easy to generate a
>> paged table with minimal effort. However there are several shortcomings
>> that I've noticed.
>>
>> 1) Documentation
>> It's quite good, but doesn't quite go far enough. There is no mention of
>> how to override cell rendering. I managed to work it out from the
>> mailing list and T5 source.
>
> Actually, there's no real documentation yet, just the
> component/parameters reference.
>
> I'll write a real document once it settles out a bit more. There's a
> lot to document there!
>
>>
>> 2) Pager presentation
>> There needs to be a way of specifying next/previous/first/last page
>> links, and their presentation.
>> There needs to be a means of controlling how many pages are listed and
>> how they are elided.
>>
>> Perhaps the option of completely custom pager presentation might be
>> worth considered.
>
> I will be doing some refactoring to make it easier to build your own
> customized Grid on top of an abstract AbsractGrid class, and the
> existing GridColumns, GridRows and GridPager components.
>
>>
>> 3) CSS classes
>> It is not possible to add your own class to the table/div. Overriding
>> the style attributes of t-data-grid is fine, but doesn't always provide
>> enough control. For example, if there is more than one grid on a page,
>> and each requires it's own styling, it's not nice.
>
> See previous note, also more parameters can be added, also you can
> hack this with JavaScript.
>
>>
>> This is really a requirement of many controls. The component supplied
>> classes will often need to be supplemented with the developers own class
>> or classes. It can be worked around, by wrapping the grid in (yet)
>> another div with a class, but that will quickly start making page and
>> component templates messier than they need to be. Sometimes the page
>> will naturally have a containing element that can fulfil this role, but
>> often it won't do.
>>
>> Maybe this isn't really a problem, and I realise that I might be alone
>> in my concern.
>
> Not quite following you on this one.
>
>>
>> 4) Lazily loaded row data
>> Consider the case where the model supplied to the grid has several
>> hundred objects, each minimally populated (perhaps with just a primary
>> key). When the grid's row property setter is called, the object can be
>> fully populated, perhaps by calling some service. So far so good.
>> However it will typically be a lot more efficient to make a single call
>> to a service to populate a batch of objects than making twenty or thirty
>> calls for each model object in a page.
>>
>> I'm not sure that this will be easy to work around, so maybe it'll just
>> have to be lived with.
>
> Right now, there's an automatic coercion from List to GridDataSource.
>
> If you check GridDataSource's interface, I think you'll find what you
> need; before it starts to render, it informs the source about the
> range of values needed, and the overall sort.
>
> For a database-based implementation of GridDataSource, this would be a
> good time to forumlate a query (including the sort) and pre-fetch the
> range of values.
>
> However, I did design this in a bit of a vacuum, so we can refine the
> interface as the real world intrudes.
>
>



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

Re: T5: Some thoughts regarding the Grid component.

[Howard Lewis Ship <hl...@gmail.com>]

On 2/27/07, Mike D Pilsbury <mi...@pekim.co.uk> wrote:
> I really like the Grid control. It's certainly very easy to generate a
> paged table with minimal effort. However there are several shortcomings
> that I've noticed.
>
> 1) Documentation
> It's quite good, but doesn't quite go far enough. There is no mention of
> how to override cell rendering. I managed to work it out from the
> mailing list and T5 source.

Actually, there's no real documentation yet, just the
component/parameters reference.

I'll write a real document once it settles out a bit more. There's a
lot to document there!

>
> 2) Pager presentation
> There needs to be a way of specifying next/previous/first/last page
> links, and their presentation.
> There needs to be a means of controlling how many pages are listed and
> how they are elided.
>
> Perhaps the option of completely custom pager presentation might be
> worth considered.

I will be doing some refactoring to make it easier to build your own
customized Grid on top of an abstract AbsractGrid class, and the
existing GridColumns, GridRows and GridPager components.

>
> 3) CSS classes
> It is not possible to add your own class to the table/div. Overriding
> the style attributes of t-data-grid is fine, but doesn't always provide
> enough control. For example, if there is more than one grid on a page,
> and each requires it's own styling, it's not nice.

See previous note, also more parameters can be added, also you can
hack this with JavaScript.

>
> This is really a requirement of many controls. The component supplied
> classes will often need to be supplemented with the developers own class
> or classes. It can be worked around, by wrapping the grid in (yet)
> another div with a class, but that will quickly start making page and
> component templates messier than they need to be. Sometimes the page
> will naturally have a containing element that can fulfil this role, but
> often it won't do.
>
> Maybe this isn't really a problem, and I realise that I might be alone
> in my concern.

Not quite following you on this one.

>
> 4) Lazily loaded row data
> Consider the case where the model supplied to the grid has several
> hundred objects, each minimally populated (perhaps with just a primary
> key). When the grid's row property setter is called, the object can be
> fully populated, perhaps by calling some service. So far so good.
> However it will typically be a lot more efficient to make a single call
> to a service to populate a batch of objects than making twenty or thirty
> calls for each model object in a page.
>
> I'm not sure that this will be easy to work around, so maybe it'll just
> have to be lived with.

Right now, there's an automatic coercion from List to GridDataSource.

If you check GridDataSource's interface, I think you'll find what you
need; before it starts to render, it informs the source about the
range of values needed, and the overall sort.

For a database-based implementation of GridDataSource, this would be a
good time to forumlate a query (including the sort) and pre-fetch the
range of values.

However, I did design this in a bit of a vacuum, so we can refine the
interface as the real world intrudes.


-- 
Howard M. Lewis Ship
TWD Consulting, Inc.
Independent J2EE / Open-Source Java Consultant
Creator and PMC Chair, Apache Tapestry
Creator, Apache HiveMind

Professional Tapestry training, mentoring, support
and project work.  http://howardlewisship.com

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