> In fact, for every Basic component, we should try to prove that you can
use composition to create the very same component from a UIBase.
This explanation and the UIBase example code that follows it is probably
good to bring up more frequently. I think it's better than a simple
reminder that Basic components should be pay-as-you-go. By seeing that a
generic UIBase can become the more complex component with the right beads,
it really cements what pay-as-you-go truly means.
- Josh
On Wed, Nov 23, 2016 at 8:40 AM, Alex Harui <aha...@adobe.com> wrote:
> I can see that I still haven't convinced folks that the Basic component
> set should not be baking things in. Separation of concerns is generally a
> good thing and, IMO, will help the framework and applications scale.
>
> The top-level component like List really only should proxy the model. In
> fact, for every Basic component, we should try to prove that you can use
> composition to create the very same component from a UIBase. IOW:
>
> <js:List dataProvider="foo" />
>
> Should be able to be written as:
>
> <js:UIBase>
> <js:beads>
> <js:ArraySelectionModel dataProvider="['foo', 'bar']" />
> <js:ListView />
> <js:SingleSelectionController />
> <js:ItemRendererFactoryForArrayData />
> </js:beads>
> </js:UIBase>
>
> That way, you can explicitly replace certain beads to get what you want,
> such as:
>
> <js:UIBase>
> <js:beads>
> <js:LinkedListOfPeopleInstancesSelectionModel
> dataProvider="{LinkedListOfPeople}" />
> <js:ListView />
> <js:CheckBoxMultipleSelectionControllerForPeopleInstances />
> <js:ItemRendererFactoryForLinkedListOfPeopleInstances />
> </js:beads>
> </js:UIBase>
>
> Which could then be re-composed as:
>
> <my:ListWithMultipleSelectionForPeopleInstances />
>
>
> So, when you look at List and DataGroup, they don't do much, because they
> aren't supposed to do much. These pieces are the "common area" the other
> beads coordinate on to display renderers, manage selection, whatever. If
> you find it convenient to bake some things together for MDL purposes
> that's fine, but the goal for Basic is to maintain separation to allow for
> maximum flexibility in composition.
>
> Another reason for having all of these replaceable parts is to allow for
> greater type-safety. In the regular Flex SDK List, both the dataProvider
> and selectedItem are of type Object because we tell folks to use this one
> List class regardless of the data. With small separate pieces in FlexJS,
> instead of accessing dataProvider and selectedItem on the List, you can
> access a strongly typed property on the various beads and know right away
> your data types did not match. In the example above, the
> LinkedListOfPeopleInstancesSelectionModel could have a dataProvider
> property of type ILinkedList and the
> CheckBoxMultipleSelectionControllerForPeopleInstances would have a
> selectedItem property of type ILinkedListItem or something like that.
>
> So, it isn't clear to me that DataGroup must have the same set of
> properties as in the regular Flex SDK. You should be able to compose all
> kinds of different combinations of renderer factories, data models and
> selection models and have them coordinate on a DataGroup. And List is
> just a convenience wrapper for those who want to give up some
> strong-typing for a more Flex-like API surface.
>
> My 2 cents,
> -Alex
>
> On 11/23/16, 7:03 AM, "Yishay Weiss" <yishayj...@hotmail.com> wrote:
>
> >Looking at List it doesn’t really do much in way of selection. All it
> >does is act as a proxy to the model which in turn keeps the selection
> >state and fires the necessary events.
> >
> >
> >
> >So I would rename List to DataGroup and get rid of the proxy methods. The
> >default model bead (defined in defaults.css) should not be
> >ArraySelectionModel but new stripped down version called ArrayModel. A
> >controller would not be necessary so I would remove that from
> >defaults.css.
> >
> >
> >
> >List would extend DataGroup, add the said proxy methods, and have the
> >same section in defaults.css it has today.
> >
> >
> >
> >How does that sound?
> >
> >
> >
> >From: Carlos Rovira<mailto:carlos.rov...@codeoscopic.com>
> >Sent: Wednesday, November 23, 2016 1:07 PM
> >To: dev@flex.apache.org<mailto:dev@flex.apache.org>
> >Subject: Re: [FlexJS] List Structure
> >
> >
> >
> >Hi Alex,
> >
> >it seems the DataGroup is not a component for direct use like in old flex
> >sdk, I tried to extend from it but doesn't know nothing about a
> >dataProvider. I think I need to wrap it. There's some docs about the
> >minimum requirements and beads needed?
> >
> >I think what we need is exactly the DataGroup as we use to have in old
> >flex
> >sdk. One that deals with dataProvider info and nothing more. Capable of
> >iterate through the data and create the associated item renderers inside
> >the container. So add, remove, but no need of selection.
> >
> >
> >
> >2016-11-23 8:43 GMT+01:00 Carlos Rovira <carlos.rov...@codeoscopic.com>:
> >
> >> Hi Alex,
> >>
> >> That would be ok, but I would like to provide data in flex way vía data
> >> provider, since is the way we have to populate List in Flex... Is like
> >> other components I introduce yesterday. I marked here :
> >> https://cwiki.apache.org/confluence/display/FLEX/Table+Of+Components
> >> to redactor and provide dataProvider API, Those are menus, tabbars ...
> >>
> >> So the following example:
> >> http://imgur.com/a/Vg0Bk
> >>
> >> could be populated with data (and so real apps)
> >>
> >> I will make a try as I get more time
> >>
> >>
> >>
> >>
> >>
> >>
> >> 2016-11-23 1:53 GMT+01:00 Alex Harui <aha...@adobe.com>:
> >>
> >>>
> >>>
> >>> On 11/22/16, 4:15 PM, "carlos.rov...@gmail.com on behalf of Carlos
> >>> Rovira"
> >>> <carlos.rov...@gmail.com on behalf of carlosrov...@apache.org> wrote:
> >>>
> >>> >2016-11-22 22:56 GMT+01:00 Alex Harui <aha...@adobe.com>:
> >>> >
> >>> >> 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.
> >>> >>
> >>> >>
> >>> >You're right Alex, MDL is second, UL with LI items, with no selection
> >>> >model, at least for what I see in the examples,
> >>> >selection seems to be in Table component...
> >>> >
> >>> >
> >>> >> 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 is clear I don't want SimpleList, maybe List...
> >>>
> >>> IMO, if you don't need selection, you should just create a new base
> >>>class
> >>> that wraps UL and OL.
> >>>
> >>> HTH,
> >>> -Alex
> >>>
> >>>
> >>
> >>
> >> --
> >>
> >> Carlos Rovira
> >> Director General
> >> M: +34 607 22 60 05
> >> http://www.codeoscopic.com
> >> http://www.avant2.es
> >>
> >> Este mensaje se dirige exclusivamente a su destinatario y puede contener
> >> información privilegiada o confidencial. Si ha recibido este mensaje por
> >> error, le rogamos que nos lo comunique inmediatamente por esta misma
> >>vía y
> >> proceda a su destrucción.
> >>
> >> De la vigente Ley Orgánica de Protección de Datos (15/1999), le
> >> comunicamos que sus datos forman parte de un fichero cuyo responsable es
> >> CODEOSCOPIC S.A. La finalidad de dicho tratamiento es facilitar la
> >> prestación del servicio o información solicitados, teniendo usted
> >>derecho
> >> de acceso, rectificación, cancelación y oposición de sus datos
> >>dirigiéndose
> >> a nuestras oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la
> >> documentación necesaria.
> >>
> >>
> >
> >
> >--
> >
> >Carlos Rovira
> >Director General
> >M: +34 607 22 60 05
> >http://www.codeoscopic.com
> >http://www.avant2.es
> >
> >Este mensaje se dirige exclusivamente a su destinatario y puede contener
> >información privilegiada o confidencial. Si ha recibido este mensaje por
> >error, le rogamos que nos lo comunique inmediatamente por esta misma vía y
> >proceda a su destrucción.
> >
> >De la vigente Ley Orgánica de Protección de Datos (15/1999), le
> >comunicamos
> >que sus datos forman parte de un fichero cuyo responsable es CODEOSCOPIC
> >S.A. La finalidad de dicho tratamiento es facilitar la prestación del
> >servicio o información solicitados, teniendo usted derecho de acceso,
> >rectificación, cancelación y oposición de sus datos dirigiéndose a
> >nuestras
> >oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la documentación
> >necesaria.
>
>
