I just remembered that there are two kinds of "lists" in HTML. There is the Select element which has a selection model, and then there is ol/ul which has no selection model. What kind of list is MDL's list? Does it support selection?
IMO, ol/ul are for displaying a list of items without a selection model. There is no promise that the children are the same. One <li> tag may have a completely different topology of child tags than the next <li> tag. AIUI, the Select element only supports plain text renderers. SimpleList was intended to wrap that. The other List provides the basis of a List with data providers, factories and item renderers. So sure, we will provide all these options, but I would not pack them into a single component, at least not in the Basic set. More inline... On 11/22/16, 1:32 PM, "carlos.rov...@gmail.com on behalf of Carlos Rovira" <carlos.rov...@gmail.com on behalf of carlos.rov...@codeoscopic.com> wrote: >> Well if it were up to me, the Basic List and SimpleList will only >>support >> the dataprovider/factory mechanism and not support setting random >> children. > > >But change itemrenderer class factory is something needed, if not we're >making the list use cases restricted. Right. What I meant was that the factory-based lists presume that all children are of the same type (or maybe a few types in a more complex case). But in OL/UL, there is no promise that any child has the same structure as the next child. >> So, for MDL, my thinking would center around what your target users >> expect. Will they be surprised or annoyed to have to learn about data >> providers in order to make a list? Would they expect to find an LI >> component? If so, then instead of extending HTML List or SimpleList, >>you >> may just want to extend Container. >> > >I think we want best of both worlds. we need to get All MDL component set, >some of them are in Flex (Button, Slider, Switch...List), but others not >(Badge, Card, Snackbar, Table...). For example, a Card could be similar to >Panel, but are not the same, so I think is wrong to try to make a Card >from >a Panel. For that reason I made Card from a basic Container, and the same >with Card subcomponents (CardActions, CardSupportingText...) > >List is a case where we want a flex behaviour (data provider, selected >Index or item, add to data provider....) but all with the look and feel of >MDL List. If we don't get the flex ease in this control, a flexjs user >will >feel disappointed about how cumbersome is to make an app without the old >flex way of list management that we all think is the right way. > >I think, I should start with flexjs List, but List component should not >"write" html tags. I think is the ListView Datagroup how needs to write >the >initial ul (with className="mdl-list"), then the item renderer will write >a >li as its root (with className="mdl-list__item-primary-content"). Maybe you want to subclass DataGroup. > >So I think we need to allow flexjs that a component in JS does not has to >write a tag and let subcomponents to do it when is needed. >If a intermediate component is designed to not write any tag but has a >subcomponent that wants to write, this should be parented to the first >parent container that writes something....makes this sense? That might end up adding significant complexity. If you don't need an intermediate component, don't create one. The View has the option to create child components or not. > >Summary, I think we're limited by the fact a flexjs component always need >to write one html tag, and we need to allow flexjs framework to let >createElement returns null (saying "hey!, I don't want to write anything >and my subcomps will be parented to my parent") > I think the View can already do this so there is no limitation. My 2 cents, -Alex
