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/03/11 13:53:14 UTC
Re: [jira] Created: (CLK-640) Add DataProvider for Table and Select
controls
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<he...@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)<ji...@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.
>>>
>>
>>
>
Re: [jira] Created: (CLK-640) Add DataProvider for Table and Select
controls
Posted by Henry Saputra <he...@gmail.com>.
But Table.getDataProvider method is tagged as public method.
I think if its only used for inheritance it would be better to set the
get/set DataProvider as protected and create additional constructor to pass
the DataProvider instance.
This way it will still be one entry point to get data from Table.
- Henry
On Thu, Mar 11, 2010 at 5:49 PM, Malcolm Edgar <ma...@gmail.com>wrote:
> 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 <he...@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 <sa...@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.
> >>>>>>
> >>>>>
> >>>>>
> >>>>
> >>>
> >>
> >
> >
>
Re: [jira] Created: (CLK-640) Add DataProvider for Table and Select
controls
Posted by Malcolm Edgar <ma...@gmail.com>.
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 <he...@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 <he...@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 <sa...@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<he...@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)<ji...@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.
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
>
Re: [jira] Created: (CLK-640) Add DataProvider for Table and Select
controls
Posted by Henry Saputra <he...@gmail.com>.
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 <he...@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 <sa...@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<he...@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)<ji...@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.
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>
Re: [jira] Created: (CLK-640) Add DataProvider for Table and Select
controls
Posted by Henry Saputra <he...@gmail.com>.
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 <sa...@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<he...@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)<ji...@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.
>>>>
>>>>
>>>
>>>
>>
>