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