I have something working now. It took a bit more doing than I'd like, but it is relatively clean. I have to create a new example for this or add it to an existing example. But here is the overview:
I created a new component called GenericList (since SimpleList is already taken). On the SWF side this is a DisplayObject and on the JS side it is a <div>. If you override createElement in the COMPILE::JS section, you could make this a <ul>. The idea is that the items generated by the itemRenderer factory become children of this component element (eg, <div> or <ul>). To do that, and make use of the existing layout code, GenericList implements IItemRendererParent (so the item renderer factory knows which parent should be used for the items it creates), ILayoutParent, and ILayoutHost. Basically, it is everything since there is no other UI elements except for the itemRenderers. GenericListView does not extend ListView because that leads to this nesting business we are trying to avoid. Instead, it just extends BeadViewBase and implements IListView (so it can provide the dataGroup for the itemRenderer factory which will be the strand/GenericList itself). This class makes sure the itemRenderer factory bead is installed and listens for changes to the dataProvider in the model. Finally, I had to copy DataItemRendererFactoryForArrayData into a new class because it explicitly references the org.apache.flex.html.List class in order to pass along the labelField to each itemRenderer. This, to me, is a problem that needs to be addressed. I probably wrote this originally, but now it must be revisited and corrected. When the beads get fired up and the dataProvider has been set, the factory discovers the dataGroup from the IListView and begins making itemRenderers. I kept with StringItemRenderer, but you could use an itemRenderer that created <li> elements on the JS side. The result HTML looks like: <div class="GenericList" …> <div class="StringItemRenderer">Widgets</div> <div class="StringItemRenderer">Thingys</div> … </div> As I said, I have to package this example up. This really makes me want to rethink a bit the complexity of the List classes, but more important, there are too many concrete classes being used instead of interfaces. Let me know if this seems more like what you are looking for. —peter On 12/2/16, 12:48 PM, "carlos.rov...@gmail.com on behalf of Carlos Rovira" <carlos.rov...@gmail.com on behalf of carlos.rov...@codeoscopic.com> wrote: >excelent Peter! I'll be waiting for this :) > >2016-12-02 15:47 GMT+01:00 Peter Ent <p...@adobe.com>: > >> I will be looking into this, this morning (shortly). Just for >>background: >> >> The ListView creates two things: an outer containment area (div) to >>house >> the chrome (scroll bars, title bars, footer bars, etc) and the content >> area (ContainerContentArea). >> >> When we first set this up, the JS side wasn't supposed to create two >> things since scroll bars are handled by the browser. But when we decided >> there were other "chrome" pieces, the nesting happened. >> >> If things are set up right, just making something an ILayoutHost the >> returns itself as the content area should be enough; its what I did for >> the MXMLItemRenderer (it is both ILayoutHost and ILayoutParent). The >> ILayoutHost is the object which returns which of its children (or >>itself) >> is the ILayoutParent. The ILayoutParent is the thing which will be the >> parent of all of the ILayoutChild objects. >> >> I will put an example together today which shows a simpler List without >> the nesting. >> >> ‹peter >> >> On 12/1/16, 7:40 PM, "Peter Ent" <p...@adobe.com> wrote: >> >> >I'll look into this tomorrow. >> > >> >Peter >> > >> > >> >On Dec 1, 2016, at 7:09 PM, Carlos Rovira <carlosrov...@apache.org> >> wrote: >> > >> >>> >> >>> Anyway, Peter might be able to better answer your question, but it >> >>>appears >> >>> that if you create some new subclass of UIBase and have it return >> >>>'this' >> >>> for layoutHost and contentView, that the ListView might then just >>stick >> >>> the children in the outer div. See how MXMLItemRenderer (which I >> >>> mentioned upthread) differs from ListBase in that way. There might >>be >> >>> some bugs to iron out, but that's my understanding of how it is >> >>>supposed >> >>> to work. >> >>> >> >>> -Alex >> >>> >> >>> >> >> Hi, >> >> >> >> Peter as Alex says you could be of great help here, hope you could >>help >> >> getting a simple example since I think is crucial for MDL List >>component >> >> (and other comps that uses the same behaviour). >> >> >> >> I'll try to investigate about layoutHost and contentView as Alex >> >>mention to >> >> be able to remove the middle div layer that List View generates. My >> >>target >> >> is to get a List that throws: >> >> >> >> <ul> >> >> <li/> >> >> <li/> >> >> </ul> >> >> >> >> and <li/> elements data will be provided by a dataProvider Array and >>the >> >> layout (the li or whatever we want) by an itemRenderer. >> >> >> >> As I get this I'll update some MDL comps that will benefit from this >> >> refactor a part from List (TabBar, NavigationBar,...) >> >> >> >> >> >> >> >> -- >> >> Carlos Rovira >> >> http://about.me/carlosrovira >> >> > > >-- > >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.
