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.
