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. >>>>> >>>>> >>>> >>>> >>> >> >
