You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@click.apache.org by Bob Schellink <sa...@gmail.com> on 2010/02/20 04:23:10 UTC
DataProvider interface
Hi all,
Currently the Table, Select and FormTable controls uses normal List objects as data providers. While
simple end easy to use it does lead to inconsistencies, for example Table rowList can be set in
onRender but Select and FormTable need to be populated before onProcess.
How about we add a DataProvider interface that can be set for all three components in the onInit
event. The Control can then call this interface when the data is needed. For Select and FormTable
this will be during the onProcess event, while Table will retrieve its data during rendering.
In addition this interface can act as a data proxy when paging. For example the DataProvider can
expose a getSize() method that returns 1000 while in reality only 10 objects were retrieved.
Ajax can also benefit from a performance perspective. Imagine making an Ajax request to a Page with
multiple Select controls and FormTable. These controls will be populated during the onInit event,
but they won't be processed because Ajax requests should only process the Control that was
interacted with.
kind regards
bob
Re: DataProvider interface
Posted by Bob Schellink <sa...@gmail.com>.
On 23/02/2010 10:08 PM, Bob Schellink wrote:
>
> Haven't thought this through but we could have the following interface:
>
> public DataProvider {
>
> public List getData(int start, int count);
Scratch that. Returning a list won't work, since the implementation would have to create a large
enough List to fit the range between start and count. Ideally I'd like the DataProvider to solve
pagination as well especially for JDBC and Lucene record sets.
bob
Re: DataProvider interface
Posted by Bob Schellink <sa...@gmail.com>.
Hi Malcolm,
Haven't thought this through but we could have the following interface:
public DataProvider {
public List getData(int start, int count);
public int getSize();
}
Example impl:
final MyDao dao = ...
table.setDataProvider(new DataProvider() {
public List getData(int start, int count) {
return dao.getCustomers(start, count);
}
public int getSize() {
return dao.getNumberOfCustomers();
}
}
kind regards
bob
On 23/02/2010 09:29 PM, Malcolm Edgar wrote:
> I have been thinking more about this, and the more I like it.
>
> One of the most common newie bugs we see with Click is the
> inappropriate use of the Page#onRender() method, i.e. people adding
> controls too late to a page to be processed or not initializing Form,
> Select, FormTable with data.
>
> Using a DataProvider the controls can pull the data when they need
> need it, rather than developers having to anticipate when the control
> needs their data. Following this programming style, I would imagine
> people composing the Page controls in the constructor setting the
> DataProvider and thats it.
>
> For example you could have a Cayenne SelectQueryDataProvider which
> implements the DataProvider interface.
>
> public CustomersPage() {
> Table table = new Table("table");
> table.addColumn(new Column('"firstName");
> table.addColumn(new Column("lastName");
>
> table.setDataProvider(new SelectQueryDataProvider
> (Customer.class, "firstName"));
>
> addControl(table);
> }
>
> This DataProvider would perform a SelectQuery(Customer.class) and
> order by "firstName" when the table needs its data.
>
> regards Malcolm Edgar
>
> On Mon, Feb 22, 2010 at 9:51 AM, Malcolm Edgar<ma...@gmail.com> wrote:
>> +1 sounds like a good idea to me, I would like to see some design
>> concepts in the WIKI
>>
>> regards Malcolm Edgar
>>
>> On Sat, Feb 20, 2010 at 2:23 PM, Bob Schellink<sa...@gmail.com> wrote:
>>> Hi all,
>>>
>>> Currently the Table, Select and FormTable controls uses normal List objects
>>> as data providers. While simple end easy to use it does lead to
>>> inconsistencies, for example Table rowList can be set in onRender but Select
>>> and FormTable need to be populated before onProcess.
>>>
>>> How about we add a DataProvider interface that can be set for all three
>>> components in the onInit event. The Control can then call this interface
>>> when the data is needed. For Select and FormTable this will be during the
>>> onProcess event, while Table will retrieve its data during rendering.
>>>
>>> In addition this interface can act as a data proxy when paging. For example
>>> the DataProvider can expose a getSize() method that returns 1000 while in
>>> reality only 10 objects were retrieved.
>>>
>>> Ajax can also benefit from a performance perspective. Imagine making an Ajax
>>> request to a Page with multiple Select controls and FormTable. These
>>> controls will be populated during the onInit event, but they won't be
>>> processed because Ajax requests should only process the Control that was
>>> interacted with.
>>>
>>> kind regards
>>>
>>> bob
>>>
>>
>
Re: DataProvider interface
Posted by Malcolm Edgar <ma...@gmail.com>.
I have been thinking more about this, and the more I like it.
One of the most common newie bugs we see with Click is the
inappropriate use of the Page#onRender() method, i.e. people adding
controls too late to a page to be processed or not initializing Form,
Select, FormTable with data.
Using a DataProvider the controls can pull the data when they need
need it, rather than developers having to anticipate when the control
needs their data. Following this programming style, I would imagine
people composing the Page controls in the constructor setting the
DataProvider and thats it.
For example you could have a Cayenne SelectQueryDataProvider which
implements the DataProvider interface.
public CustomersPage() {
Table table = new Table("table");
table.addColumn(new Column('"firstName");
table.addColumn(new Column("lastName");
table.setDataProvider(new SelectQueryDataProvider
(Customer.class, "firstName"));
addControl(table);
}
This DataProvider would perform a SelectQuery(Customer.class) and
order by "firstName" when the table needs its data.
regards Malcolm Edgar
On Mon, Feb 22, 2010 at 9:51 AM, Malcolm Edgar <ma...@gmail.com> wrote:
> +1 sounds like a good idea to me, I would like to see some design
> concepts in the WIKI
>
> regards Malcolm Edgar
>
> On Sat, Feb 20, 2010 at 2:23 PM, Bob Schellink <sa...@gmail.com> wrote:
>> Hi all,
>>
>> Currently the Table, Select and FormTable controls uses normal List objects
>> as data providers. While simple end easy to use it does lead to
>> inconsistencies, for example Table rowList can be set in onRender but Select
>> and FormTable need to be populated before onProcess.
>>
>> How about we add a DataProvider interface that can be set for all three
>> components in the onInit event. The Control can then call this interface
>> when the data is needed. For Select and FormTable this will be during the
>> onProcess event, while Table will retrieve its data during rendering.
>>
>> In addition this interface can act as a data proxy when paging. For example
>> the DataProvider can expose a getSize() method that returns 1000 while in
>> reality only 10 objects were retrieved.
>>
>> Ajax can also benefit from a performance perspective. Imagine making an Ajax
>> request to a Page with multiple Select controls and FormTable. These
>> controls will be populated during the onInit event, but they won't be
>> processed because Ajax requests should only process the Control that was
>> interacted with.
>>
>> kind regards
>>
>> bob
>>
>
Re: DataProvider interface
Posted by Malcolm Edgar <ma...@gmail.com>.
+1 sounds like a good idea to me, I would like to see some design
concepts in the WIKI
regards Malcolm Edgar
On Sat, Feb 20, 2010 at 2:23 PM, Bob Schellink <sa...@gmail.com> wrote:
> Hi all,
>
> Currently the Table, Select and FormTable controls uses normal List objects
> as data providers. While simple end easy to use it does lead to
> inconsistencies, for example Table rowList can be set in onRender but Select
> and FormTable need to be populated before onProcess.
>
> How about we add a DataProvider interface that can be set for all three
> components in the onInit event. The Control can then call this interface
> when the data is needed. For Select and FormTable this will be during the
> onProcess event, while Table will retrieve its data during rendering.
>
> In addition this interface can act as a data proxy when paging. For example
> the DataProvider can expose a getSize() method that returns 1000 while in
> reality only 10 objects were retrieved.
>
> Ajax can also benefit from a performance perspective. Imagine making an Ajax
> request to a Page with multiple Select controls and FormTable. These
> controls will be populated during the onInit event, but they won't be
> processed because Ajax requests should only process the Control that was
> interacted with.
>
> kind regards
>
> bob
>