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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> 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<[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. >>>>>> >>>>> >>>>> >>>> >>> >> > >
