On 11/23/16, 1:59 PM, "carlos.rov...@gmail.com on behalf of Carlos Rovira" <carlos.rov...@gmail.com on behalf of carlos.rov...@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 xmlns:ui=org.apache.flex.core > > >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. Thoughts? -Alex > > > > >2016-11-23 22:52 GMT+01:00 Alex Harui <aha...@adobe.com>: > >> >> >> On 11/23/16, 1:09 PM, "yishayw" <yishayj...@hotmail.com> wrote: >> >> >Alex, >> > >> >If you read my post carefully you'll see I'm suggesting to separate >>some >> >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 >>List >> >as is or even extend it. I'm suggesting that List (renamed to >>DataGroup) >> >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 >>List/ListBase? >> >> -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.
