Hi,
just integrate the new List component and beads in MDL. As I changed it and
introduced a custom item renderer (called
itemRenderers/ListItemRenderer.as) in MDLExample (that is what people will
do), I found a strange behaviour. The custom IR is running since I put a
trace statement and I see one trace for each item renderer. but the
createElement is not running, I'm getting:
<ul class=" mdl-list" style="width: 8px;">
<div class="" style="position: relative; display: block;"></div>
<div class="" style="position: relative; display: block;"></div>
<div class="" style="position: relative; display: block;"></div>
<div class="" style="position: relative; display: block;"></div>
</ul>
the inner divs was having in other test class="DataItemRenderer"
but I have a createElement method in my ItemRenderer:
/**
* @flexjsignorecoercion org.apache.flex.core.WrappedHTMLElement
*/
COMPILE::JS
override protected function createElement():WrappedHTMLElement
{
typeNames = "mdl-list__item";
element = document.createElement('li') as WrappedHTMLElement;
positioner = element;
element.flexjs_wrapper = this;
// itemRenderers should provide something for the background to
handle
// the selection and highlight
backgroundView = element;
return element;
}
Do you know what could be happen here? After lots of test I'm lost...
2016-12-02 23:27 GMT+01:00 Carlos Rovira <carlos.rov...@codeoscopic.com>:
> Hi Peter,
>
> so cool! I just created the pom.xml and fill the licenses to build with
> maven. Run the example and check the code. I still eating that food to be
> able to comment, but seems what I expect :)
>
> So many thanks, I'll be playing with it in the following days to apply to
> MDL components
>
> I think Alex and you has some issue that you want to work on, I'll be
> incorporating whatever upgrade you made. I think this is an important
> component where the power of flex comes clearly and if we could get as
> simpler as possible that will be great.
>
> Thanks!
>
> Carlos
>
>
>
> 2016-12-02 22:37 GMT+01:00 Alex Harui <aha...@adobe.com>:
>
>> This seems mostly right to me. The top-level component is aggregating the
>> interfaces onto itself. More inline...
>>
>> On 12/2/16, 12:41 PM, "Peter Ent" <p...@adobe.com> wrote:
>> >
>> >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.
>>
>> Isn't the real issue that it is ContainerView that ListView extends that
>> makes the assumption that it has to add a viewport to the strand? I think
>> that's ok though. As Harbs said in another thread, or maybe upthread,
>> there will be Container views for heavy containers with inner content
>> areas and Container views for lightweight containers without inner content
>> areas. The current ContainerView is the heavy one. You have probably
>> just written the lightweight one or can factor it out of your
>> GenericListView. Might be time to rename the current ContainerView to
>> ContainerWithContentAreaView and make the lighter one the new
>> ContainerView.
>>
>> >
>> >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.
>>
>> In theory, the labelField should be in the model and retrieved from there.
>>
>> My 2 cents,
>> -Alex
>>
>>
>
>
> --
>
> Carlos Rovira
> Director General
> M: +34 607 22 60 05 <607%2022%2060%2005>
> 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.
>
>
--
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.
