Re: [FlexJS] (Att: Peter Ent) Get rid of extra divs layers we don't want (was Re: [FlexJS]Layout problems)

[Alex Harui]

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.

The ListItemRenderer.js doesn't have a createElement call because
COMPILE::JS must be false during the cross-compile.  You might be able to
turn it on, or move the renderer into a library SWC.

HTH,
-Alex

On 12/3/16, 12:30 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
 wrote:

>Hi Alex,
>
>I uploaded all my code in the two last commits so you can see it. Is
>mostly
>Peter's Code but the itemRenderer is a copy of StringItemRenderer but put
>the class in the project example (since people will use normaly a List
>with
>different IRs. I had to remove the related SWF code since compiler was
>unable to find class
>
>org.apache.flex.core.CSSTextField
>
>what seems to me very Strange.
>
>Since StringItemRenderers extends DataItemRenderer, I think something very
>strange is happening under the hood as set data code is running from my
>code (I see the traces) but instead of createElement from my class (that
>outputs li) it seems running code from DataItemRenderer (the superclass).
>
>Regarding VerticalLayout, I can remove the layout from CSS declaration and
>leave blank? or is mandatory bead
>
>thanks
>
>
>2016-12-03 2:37 GMT+01:00 Alex Harui :
>
>> What does your code look like?  Sounds like DataItemRenderers are still
>> being created and added.
>>
>> I think the display: block is from VerticalLayout.  It uses that to tell
>> the browser to lay things out vertically.  position: relative might also
>> come from the layout or some container logic as we've seen before.
>>
>> -Alex
>>
>> On 12/2/16, 4:41 PM, "carlos.rov...@gmail.com on behalf of Carlos
>>Rovira"
>> 
>> wrote:
>>
>> >One more thing,
>> >Where come from the 8px width in List?
>> >The styles in items are as well suspicious
>> >
>> >
>> >2016-12-03 1:37 GMT+01:00 Carlos Rovira
>>:
>> >
>> >> 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:
>> >>
>> >> 
>> >> 
>> >> 
>> >> 
>> >> 
>> >> 
>> >>
>> >> 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
>> >>:
>> >>
>> >>> 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 :
>> >>>
>>  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"  wrote:
>>  >
>>  >GenericListView does not extend ListView because 

Re: [FlexJS] (Att: Peter Ent) Get rid of extra divs layers we don't want (was Re: [FlexJS]Layout problems)

[Carlos Rovira]

Hi Alex,

I uploaded all my code in the two last commits so you can see it. Is mostly
Peter's Code but the itemRenderer is a copy of StringItemRenderer but put
the class in the project example (since people will use normaly a List with
different IRs. I had to remove the related SWF code since compiler was
unable to find class

org.apache.flex.core.CSSTextField

what seems to me very Strange.

Since StringItemRenderers extends DataItemRenderer, I think something very
strange is happening under the hood as set data code is running from my
code (I see the traces) but instead of createElement from my class (that
outputs li) it seems running code from DataItemRenderer (the superclass).

Regarding VerticalLayout, I can remove the layout from CSS declaration and
leave blank? or is mandatory bead

thanks


2016-12-03 2:37 GMT+01:00 Alex Harui :

> What does your code look like?  Sounds like DataItemRenderers are still
> being created and added.
>
> I think the display: block is from VerticalLayout.  It uses that to tell
> the browser to lay things out vertically.  position: relative might also
> come from the layout or some container logic as we've seen before.
>
> -Alex
>
> On 12/2/16, 4:41 PM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
> 
> wrote:
>
> >One more thing,
> >Where come from the 8px width in List?
> >The styles in items are as well suspicious
> >
> >
> >2016-12-03 1:37 GMT+01:00 Carlos Rovira :
> >
> >> 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:
> >>
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >>
> >> 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
> >>:
> >>
> >>> 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 :
> >>>
>  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"  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
> 

Re: [FlexJS] (Att: Peter Ent) Get rid of extra divs layers we don't want (was Re: [FlexJS]Layout problems)

[Alex Harui]

What does your code look like?  Sounds like DataItemRenderers are still
being created and added.

I think the display: block is from VerticalLayout.  It uses that to tell
the browser to lay things out vertically.  position: relative might also
come from the layout or some container logic as we've seen before.

-Alex

On 12/2/16, 4:41 PM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
 wrote:

>One more thing,
>Where come from the 8px width in List?
>The styles in items are as well suspicious
>
>
>2016-12-03 1:37 GMT+01:00 Carlos Rovira :
>
>> 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:
>>
>> 
>> 
>> 
>> 
>> 
>> 
>>
>> 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
>>:
>>
>>> 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 :
>>>
 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"  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 

Re: [FlexJS] (Att: Peter Ent) Get rid of extra divs layers we don't want (was Re: [FlexJS]Layout problems)

[Carlos Rovira]

One more thing,
Where come from the 8px width in List?
The styles in items are as well suspicious


2016-12-03 1:37 GMT+01:00 Carlos Rovira :

> 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:
>
> 
> 
> 
> 
> 
> 
>
> 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 :
>
>> 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 :
>>
>>> 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"  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 

Re: [FlexJS] (Att: Peter Ent) Get rid of extra divs layers we don't want (was Re: [FlexJS]Layout problems)

[Carlos Rovira]

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:








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 :

> 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 :
>
>> 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"  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 

Re: [FlexJS] (Att: Peter Ent) Get rid of extra divs layers we don't want (was Re: [FlexJS]Layout problems)

[Carlos Rovira]

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 :

> 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"  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
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.

Re: [FlexJS] (Att: Peter Ent) Get rid of extra divs layers we don't want (was Re: [FlexJS]Layout problems)

[Alex Harui]

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"  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

Re: [FlexJS] (Att: Peter Ent) Get rid of extra divs layers we don't want (was Re: [FlexJS]Layout problems)

[Peter Ent]

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"  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
>. If you override createElement in the COMPILE::JS section, you could
>make this a .
>
>The idea is that the items generated by the itemRenderer factory become
>children of this component element (eg,  or ). 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  elements on the JS side.
>
>The result HTML looks like:
>
>
>   Widgets
>   Thingys
>…
>
>
>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"
>
>wrote:
>
>>excelent Peter! I'll be waiting for this :)
>>
>>2016-12-02 15:47 GMT+01:00 Peter Ent :
>>
>>> 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"  wrote:
>>>
>>> >I'll look into this tomorrow.
>>> >
>>> >Peter
>>> >
>>> >
>>> >On Dec 1, 2016, at 7:09 PM, Carlos Rovira 
>>> 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 

Re: [FlexJS] (Att: Peter Ent) Get rid of extra divs layers we don't want (was Re: [FlexJS]Layout problems)

[Peter Ent]

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
. If you override createElement in the COMPILE::JS section, you could
make this a .

The idea is that the items generated by the itemRenderer factory become
children of this component element (eg,  or ). 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  elements on the JS side.

The result HTML looks like:


   Widgets
   Thingys
…


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"
 wrote:

>excelent Peter! I'll be waiting for this :)
>
>2016-12-02 15:47 GMT+01:00 Peter Ent :
>
>> 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"  wrote:
>>
>> >I'll look into this tomorrow.
>> >
>> >Peter
>> >
>> >
>> >On Dec 1, 2016, at 7:09 PM, Carlos Rovira 
>> 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:
>> >>
>> >> 
>> >>   
>> >>   
>> >> 
>> >>
>> >> and  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, 

Re: [FlexJS] (Att: Peter Ent) Get rid of extra divs layers we don't want (was Re: [FlexJS]Layout problems)

[Carlos Rovira]

excelent Peter! I'll be waiting for this :)

2016-12-02 15:47 GMT+01:00 Peter Ent :

> 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"  wrote:
>
> >I'll look into this tomorrow.
> >
> >Peter
> >
> >
> >On Dec 1, 2016, at 7:09 PM, Carlos Rovira 
> 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:
> >>
> >> 
> >>   
> >>   
> >> 
> >>
> >> and  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.

Re: [FlexJS] (Att: Peter Ent) Get rid of extra divs layers we don't want (was Re: [FlexJS]Layout problems)

[Peter Ent]

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"  wrote:

>I'll look into this tomorrow.
>
>Peter 
>
>
>On Dec 1, 2016, at 7:09 PM, Carlos Rovira  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:
>> 
>> 
>>   
>>   
>> 
>> 
>> and  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

Re: [FlexJS] (Att: Peter Ent) Get rid of extra divs layers we don't want (was Re: [FlexJS]Layout problems)

[Peter Ent]

I'll look into this tomorrow. 

Peter 


On Dec 1, 2016, at 7:09 PM, Carlos Rovira  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:
> 
> 
>   
>   
> 
> 
> and  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