flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com>
Subject Re: [FlexJS] List Structure
Date Wed, 23 Nov 2016 22:53:29 GMT

On 11/23/16, 1:59 PM, "carlos.rovira@gmail.com on behalf of Carlos Rovira"
<carlos.rovira@gmail.com on behalf of carlos.rovira@codeoscopic.com> wrote:

>More over, If I put only <jsUIBase/>
>it fails the same way

Well, that was more of an illustration.  UIBase isn't currently in the
basic-manifest since most folks won't be using it in MXML.  But I don't
have any objections to adding it.  There are just so many more classes in
FlexJS than in Flex because we have separation of concerns that I was
concerned about how many things would show up in code hinting.  If you
want to experiment with "exploded" components, you could add UIBase to the
manifest or just access it with a custom xmlns like

>Regarding DataGroup, If I try to instantiate <js:DataGroup/> it fails in
>the same way like UIBase
>If I try to extend it (mdl List extends DataGroup) I can't use
>dataProvider,...so DataGroup by itself is a useless component, I think is
>not like the one in old flex sdk, it needs more things (but don't know the
>basic requerimients)

I guess the point of my earlier long email was that folks are still in the
subclassing mentality rather than the composition mentality.  Is there
really a reason you "must" subclass some higher-level component in the
HTML.swc in order to make your MDL List, or should you just be trying to
compose a new component and re-use the parts from HTML.swc like the
renderer factory?

Datagroup isn't in the manifest as it isn't meant to be a top-level
component.  I don't know of any reason for DataGroup to be anything other
than a common area for other beads to share.  It that sense, I don't think
it needs any other properties nor does it need to be a base class for
other top-level components.  Composition is a different way of thinking,
but I think there is evidence in the code we have already that it is a win
in many ways (encapsulation, code size, dependency management, etc).  If
we don't like the name, we can change it.

Now, I wouldn't put any money that we got the interfaces right in all of
the beads that List works with, so I won't be surprised if some tweaks are
needed.  But for now, the term "List" in the HTML.swc is being used the
same way it was in the Flex SDK.  It provides selection.  If you want to
create something else that has a data provider, renderers, and no
selection, you might just extend UIBase or Container and hopefully re-use
many of the same beads that List currently uses.  If this is the thing you
want to call DataGroup, I suppose that is ok, but we aren't using Group
anywhere in FlexJS right now.  Maybe we should rename List to
SelectableList or ListWithSelection and give up on re-using the term from
the Flex SDK.


>2016-11-23 22:52 GMT+01:00 Alex Harui <aharui@adobe.com>:
>> On 11/23/16, 1:09 PM, "yishayw" <yishayjobs@hotmail.com> wrote:
>> >Alex,
>> >
>> >If you read my post carefully you'll see I'm suggesting to separate
>> >concerns that are now baked into List. Currently there's selection and
>> >data
>> >rendering baked into List. That's the reason Carlos couldn't just use
>> >as is or even extend it. I'm suggesting that List (renamed to
>> >only deal with data rendering.
>> >
>> List is a top-level component.  It is supposed to bake in some things.
>> I guess I don't quite get what changes you are proposing.  What's wrong
>> with the current DataGroup?  Why does Carlos need to extend
>> -Alex
>Carlos Rovira
>Director General
>M: +34 607 22 60 05
>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
>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
>oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la documentación

View raw message