I've checked in a new example: flex-asjs/examples/flexjs/ListExample. Let me know if this is close to what you are looking for.
—peter On 12/2/16, 3:41 PM, "Peter Ent" <p...@adobe.com> wrote: >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. >
