click-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henry Saputra <henry.sapu...@gmail.com>
Subject Re: [jira] Created: (CLK-640) Add DataProvider for Table and Select controls
Date Thu, 11 Mar 2010 19:47:04 GMT
Hi Bob, Malcolm,

Well yeah but I think it could be use in stateless environment too =)

The only reason I was proposing model is to hide developer for providing
data to Clck components and from component developer from accessing raw data
methods like Java collection APIs.

With well defined Model APIs we could provide a thin abstraction between
component and the data structure native methods.

- Henry

On Thu, Mar 11, 2010 at 4:53 AM, Bob Schellink <sabob1@gmail.com> wrote:

> 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<henry.saputra@gmail.com>
>>  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)<jira@apache.org>
>>> 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.
>>>>
>>>>
>>>
>>>
>>
>

Mime
View raw message