Hi Henry,
Having the concept of an abstracted model is useful in stateful environments, but as Click is a
mostly stateless, I think it will be overkill for the majority of use cases. Good idea though.
kind regards
bob
On 11/03/2010 12:38 PM, Malcolm Edgar wrote:
Hi Henry,
What the DataProvider is trying to achieve is relatively simple,
simply load list data on demand for controls which need it, e.g. Table
and Select.
The DataModel concept I think you have is much broader, more like
Swing models and data binding. I think is a broader discussion which
involves issues of:
* on demand data loading
* bi-directional data binding
* changing control implementations
A proposal like this has a lot of backward compatibility issues which
need to be assessed.
One of the big challenges with moving Apache Click forward is
maintaining backward compatibility (or at worst an acceptable
migration path). When looking at new features the first question I
think if is what is it going to break?
regards Malcolm Edgar
On Thu, Mar 11, 2010 at 10:56 AM, Henry Saputra<[email protected]> wrote:
HI Malcolm,
Instead of DataProvider maybe we could call it DataModel since its purpose
basically to provide "model" for the UI components.
This model will provide abstraction for many data providers if necessary.
It will look something like this:
public interface DataModel{
// public APIs for data access
public Object getRawData();
public void setRawData(Object data);
public int getRowCount();
// state management
public boolean isActiveRow(); // return false if the model is stateless
or no active row exist in the current index
public Object getRowIndex();
public void setRowIndex(int index);
public Object getRowData();
}
For DataModel to use with Java collection we could add a CollectionModel
class which wraps a Java Collection object:
public CollectionModel implements DataModel {
private final Collection<? extends Object> rawData;
...
public CollectionModel(java.util.Collection<? extends Object> data) {
rawData = data;
}
// implement DataModel APIs
....
}
The DataModel then could be extended to cover hierarchical model to support
tree or other complex components.
The idea is to wrap the raw collection/source data with Click model to
component developers dont have to deal wirh raw data directly.
Any thoughts?
- Henry
On Sat, Mar 6, 2010 at 1:43 AM, Malcolm Edgar (JIRA)<[email protected]>
wrote:
Add DataProvider for Table and Select controls
----------------------------------------------
Key: CLK-640
URL: https://issues.apache.org/jira/browse/CLK-640
Project: Click
Issue Type: New Feature
Components: core
Affects Versions: 2.1.0
Reporter: Malcolm Edgar
Fix For: 2.2.0
One reoccurring problem we see with people using Click is the
inappropriate use of the Page#onRender() method. Typically its used to set
data into the Table control, but then people will often use this Page method
to set data in other controls such as the FormTable or Select controls,
which breaks their usage contract.
What I would like to see is that data controls such as the Table, Select
and FormTable are able to load the data when they need it, rather than
having to rely on the developer injecting the data at the correct point in
the pages life cycle. This will provide an improve programming model where
developers simply create their controls in the Page constructor or onInit()
method, configure data providers when necessary, and write up control event
handlers to the appropriate methods.
The DataProvider interface would be very simple:
public interface DataProvider {
public List getData();
}
Developers would then implement this interface when creating their
controls:
Table table = new Table();
table.addColumn()
...
table.setDataProvider(new DataProvider() {
public List getData() {
return customerDao.getCustomerList();
}
});
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
