See MXMLItemRenderer. You either want to have a default layout or assign one. A parent sizes its children and if no layout is specified the children do not get size. Check the DOM to make sure all of the elements got created.
It could also be that the renderer itself doesn't have a good size. -Alex On 12/8/16, 11:14 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira" <carlos.rov...@gmail.com on behalf of carlos.rov...@codeoscopic.com> wrote: >Ok, I follow your indications and created a ListItemRenderer ni MDL swc, >this will be the basic IR and outputs LI with appropriate MDL class. > >Now, I want this renderer to be able to be customized on user project >(MDLExample), so to test I did: > ><mdl:ListItemRenderer xmlns:fx="http://ns.adobe.com/mxml/2009"; > xmlns:js="library://ns.apache.org/flexjs/basic" > xmlns:mdl="library://ns.apache.org/flexjs/mdl" > xmlns="http://www.w3.org/1999/xhtml";> > > <js:Container> > <js:Span text="hello"/> > > </js:Container> > ></mdl:ListItemRenderer> > >This is not working and I think is because the basic DataItemRenderer >comes >from UIBase. >I tried in local to redo the inheritance and do this: > >public class ListItemRenderer extends ContainerBase implements >ISelectableItemRenderer > >(following what I see in Yishay AccordionItemRenderer (difference is that >one is extending from Panel) > >But I can't get this to show: > > <js:Container> > <js:Span text="hello"/> > > </js:Container> > >How I can get that output? > >Thanks > > > >2016-12-05 17:21 GMT+01:00 Alex Harui <aha...@adobe.com>: > >> >> >> On 12/5/16, 3:39 AM, "carlos.rov...@gmail.com on behalf of Carlos >>Rovira" >> <carlos.rov...@gmail.com on behalf of carlosrov...@apache.org> wrote: >> >> >Hi Alex, >> > >> >to introduce the problem: >> > >> >I took a look and saw that your ListItemRenderer is in the application >> >> project, not a library project, but it contains conditional compile >> >>code. >> >> I'm not sure we've ironed out that workflow. The main idea was that >> >> application developers wouldn't need conditional compilation. All >>APIs >> >> they would need would be cross-platform and all the platform-specific >> >> stuff would be encapsulated into the library SWCs. >> >> >> >> >> >mmm...I was thinking on that decision and I think it should be hard to >> >make >> >devs understand that they >> >can't do that in their projects. >> > >> >I think use case like custom item renderers are very common. We should >> >expect FlexJS users writing >> >custom IR a lot in their apps. If they are writing a complex >>app...should >> >be normal to has one or more swc libs >> >created by them, but we all now that one of the powers of flex is make >>a >> >fast app in one single project and even >> >in few files (classes). So I think, although I understand the decision >>and >> >intention, I think that is not practical. >> >> As Yishay says, custom item renderers should be possible without >> platform-specific code. If you had a base class in the framework that >> wrapped LI then you probably wouldn't have any conditional compile in >>your >> renderer. Still, we should allow for it at some point. >> >> > >> >btw, you pointed me to change COMPILE::JS to true, but how I can do >>this? >> >I see that in some build.xml but no in pom.xml. So although I search, I >> >don't know how to do this right now. >> >Some clue or where to dig? >> >> Well for Ant and FB integration, it is as simple as adding the compiler >> flags. I think for Maven this sort of thing is buried in the Mojo, but >>I >> would think you could use the additional compiler options to set it for >> now. >> >> -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.
