click-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Malcolm Edgar <malcolm.ed...@gmail.com>
Subject Re: [jira] Created: (CLK-640) Add DataProvider for Table and Select controls
Date Fri, 12 Mar 2010 01:49:25 GMT
Hi Henry,

As general principle Click classes should use the getter methods to
access properties, rather than the protected fields.
One of the major benefits of having a getter is to enable Table
subclasses to override this implementation.

regards Malcolm Edgar

On Fri, Mar 12, 2010 at 12:24 PM, Henry Saputra <henry.saputra@gmail.com> wrote:
> Hi Malcolm,
> Since Table already have getRowList public method to get the data, would
> exposing getDataProvider as public method become a bit confusing.
> - Henry
>
> On Thu, Mar 11, 2010 at 11:47 AM, Henry Saputra <henry.saputra@gmail.com>
> wrote:
>>
>> 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