Re: [FlexJS] get rid of inline styles (was Re: [FlexJS]Layout problems)
In Radiate I convert Flex UIComponents to HTML components and had this
problem. I made an option to allow styles to be defined inline or in a
style sheet. If the option was stylesheet then if the component had an id
the styles were declared by id. This included position, size, etc:
#myLabel {
style: value;
}
If the component didn't have an id too bad. I'd give it an id using Flex
naming utils class and again declare styles there.
But I added an option to let developers override the styles per component
and that might work here.
So you would have a components style declaration by id and then in Radiate
there is a user styles field. Any values in that field would be declared in
the style declaration but they would be placed at the end. Everybody knows
that last declaration wins, even grandma.
#myLabel {
style: value; /*define by framework */
style: newValue; /* defined by user */
}
You could also declare style: inherit and I think that resets the value.
Yes, the style is declared twice. Who cares. But yes to look pretty, I plan
to remove the first declaration or comment it out in a future update.
If Flex JS made some combination of class and class#id it might be an
option so that you can declare your own style declaration afterwards and
restore the defaults. Yes there might be two style declarations but at
least then they wouldn't be defined inline.
On Dec 2, 2016 11:52 AM, "Carlos Rovira"
wrote:
> Hi Josh,
>
> right. As I get some few components more, I think I could refactor removing
> the dependencies from some HTML comps so we could manage better MDL set. So
> for example, I will took things from Core, like UIBase or ContainerBase
> while removing html things like TextButton, Container and so on...(in the
> end removing HTML.swc dependency at all). In this way I think MDL will be
> more independent.
>
> 2016-12-02 16:55 GMT+01:00 Josh Tynjala :
>
> > Alex's first point about using the same beads, but not subclassing sounds
> > cleaner to me, Carlos. Kind of the same idea from the other day where all
> > components should be possible to recreate from UIBase with the right set
> of
> > beads. You should consider trying that out for MDL.
> >
> > - Josh
> >
> > On Dec 1, 2016 11:09 PM, "Alex Harui" wrote:
> >
> > > Re-ordering your post so I can address higher-level points first:
> > >
> > >
> > > On 12/1/16, 4:55 PM, "carlos.rov...@gmail.com on behalf of Carlos
> > Rovira"
> > > wrote:
> > > >
> > > >But Basic set is at the core of
> > > >all. Is at the core of MDL set
> > > >
> > > >
> > >
> > > This statement doesn't have to be true, and makes me think that the old
> > > Flex SDK mentality is persisting. IMO, the MDL set has no obligation
> to
> > > subclass the Basic set. The top-level components in the Basic set are
> > > supposed to be compositions of beads. MDL can just compose the same or
> > > different beads without having to subclass Basic components.
> > >
> > > One of the problems of having a core and inheritance is that you have
> to
> > > get it right, but often there isn't one right answer.
> > >
> > > >I think
> > > >Basic set (as is) will not be used at all since the final visuals are
> > not
> > > >production ready, so you know people will need this level of
> > customization
> > > >or they will never join FleJS for sure. and here you have the first
> > > >example of many
> > > >of the styles in flexjs needs to be removed in order to get the MDL
> > branch
> > > >working ok, and so will happen with others like Bootstrap, and so
> on...
> > > >Only if we create our own FlexJS style design could take into account
> > the
> > > >actual styles, but I think that if MDL or Bootstrap does not need all
> of
> > > >that, we should not need creating our own CSS set in the end (I can't
> > say
> > > >much more here since I'm not a CSS expert to affirm that, but based on
> > > >what
> > > >I see...is clear that it's the reality).
> > > >
> > >
> > > In my mind, there are going to be two kinds of themes: pre-existing
> ones
> > > like MDL and custom ones like the themes that regular Flex SDK
> customers
> > > used to brand their applications. In the second kind, I don't think it
> > > matters as much as to what default styles are. Folks will simply
> override
> > > the defaults in their themes.
> > >
> > > I was a bit surprised that MDL didn't override everything we set as
> > > defaults for HTML.swc. That means to me that if someone has certain
> > > styles set elsewhere, even in their browser settings, that could cause
> > > really strange and unexpected results. But OK, that's the way it is,
> and
> > > so we should think of other ways to have a default look for HTML.swc,
> > > although again, as I said above, the MDL library has no obligation to
> > > inherit from HTML.swc.
> > >
> > > If we really need to support more inheritance, then maybe all visual
> > > styles should be moved from HTML into some default theme. It would be
> > > nice to have a better set of d
Re: [FlexJS] (Att: Peter Ent) Get rid of extra divs layers we don't want (was Re: [FlexJS]Layout problems)
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 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 stran
Re: [FlexJS] (Att: Peter Ent) Get rid of extra divs layers we don't want (was Re: [FlexJS]Layout problems)
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
> just written the lightweight one or can factor it out of your
> GenericListView. Might be time to rename the current ContainerView to
> ContainerWithContentAreaView and m
Re: [FlexJS] (Att: Peter Ent) Get rid of extra divs layers we don't want (was Re: [FlexJS]Layout problems)
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 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
Re: [FlexJS] (Att: Peter Ent) Get rid of extra divs layers we don't want (was Re: [FlexJS]Layout problems)
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 <607%2022%2060%2005>
> http://www.codeoscopic.com
> http://www.avant2.es
>
> Este mensaje se dirige exclusivamente a
Re: [FlexJS] (Att: Peter Ent) Get rid of extra divs layers we don't want (was Re: [FlexJS]Layout problems)
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 datos forman parte de un fichero cuyo responsable es CODEOSCOPIC
S.A.
Re: [FlexJS] (Att: Peter Ent) Get rid of extra divs layers we don't want (was Re: [FlexJS]Layout problems)
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)
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)
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 throws: >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> and elements data will be provided by a dataProvider Array and >>>the >>> >> lay
Re: [FlexJS] (Att: Peter Ent) Get rid of extra divs layers we don't want (was Re: [FlexJS]Layout problems)
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, NavigationBar,...) >> >> >> >> >> >> >> >> -- >> >> Carlos Rovira >> >> http://about.me/carlosrovira >> >> > > >-- > >Carlos Rovira >Direct
Re: [FlexJS] get rid of inline styles (was Re: [FlexJS]Layout problems)
Hi Josh, right. As I get some few components more, I think I could refactor removing the dependencies from some HTML comps so we could manage better MDL set. So for example, I will took things from Core, like UIBase or ContainerBase while removing html things like TextButton, Container and so on...(in the end removing HTML.swc dependency at all). In this way I think MDL will be more independent. 2016-12-02 16:55 GMT+01:00 Josh Tynjala : > Alex's first point about using the same beads, but not subclassing sounds > cleaner to me, Carlos. Kind of the same idea from the other day where all > components should be possible to recreate from UIBase with the right set of > beads. You should consider trying that out for MDL. > > - Josh > > On Dec 1, 2016 11:09 PM, "Alex Harui" wrote: > > > Re-ordering your post so I can address higher-level points first: > > > > > > On 12/1/16, 4:55 PM, "carlos.rov...@gmail.com on behalf of Carlos > Rovira" > > wrote: > > > > > >But Basic set is at the core of > > >all. Is at the core of MDL set > > > > > > > > > > This statement doesn't have to be true, and makes me think that the old > > Flex SDK mentality is persisting. IMO, the MDL set has no obligation to > > subclass the Basic set. The top-level components in the Basic set are > > supposed to be compositions of beads. MDL can just compose the same or > > different beads without having to subclass Basic components. > > > > One of the problems of having a core and inheritance is that you have to > > get it right, but often there isn't one right answer. > > > > >I think > > >Basic set (as is) will not be used at all since the final visuals are > not > > >production ready, so you know people will need this level of > customization > > >or they will never join FleJS for sure. and here you have the first > > >example of many > > >of the styles in flexjs needs to be removed in order to get the MDL > branch > > >working ok, and so will happen with others like Bootstrap, and so on... > > >Only if we create our own FlexJS style design could take into account > the > > >actual styles, but I think that if MDL or Bootstrap does not need all of > > >that, we should not need creating our own CSS set in the end (I can't > say > > >much more here since I'm not a CSS expert to affirm that, but based on > > >what > > >I see...is clear that it's the reality). > > > > > > > In my mind, there are going to be two kinds of themes: pre-existing ones > > like MDL and custom ones like the themes that regular Flex SDK customers > > used to brand their applications. In the second kind, I don't think it > > matters as much as to what default styles are. Folks will simply override > > the defaults in their themes. > > > > I was a bit surprised that MDL didn't override everything we set as > > defaults for HTML.swc. That means to me that if someone has certain > > styles set elsewhere, even in their browser settings, that could cause > > really strange and unexpected results. But OK, that's the way it is, and > > so we should think of other ways to have a default look for HTML.swc, > > although again, as I said above, the MDL library has no obligation to > > inherit from HTML.swc. > > > > If we really need to support more inheritance, then maybe all visual > > styles should be moved from HTML into some default theme. It would be > > nice to have a better set of defaults that are a bit more production > ready > > for Basic so we can see how and why there are collisions between themes. > > > > >You could as well use documentation to expose requirements and make > people > > >know that 2 or 3 styles are required and if they remove from CSS things > > >could break. We could prepare as well a MVCSS (minimum viable CSS) so > > >people would not need to use the remove default compiler flag, and have > > >another with relative positions, borders and other no-so required > things, > > >but needed in basic comp set. > > > > > > > > > > Way back in early Flex, we found our customers didn't like this. There > > was a version of Flex where only the type-selectors with the same name as > > the component was applied. So CheckBox extended Button and lots of > styles > > important to Button needed to be copied to the CheckBox type selector. > > This was way faster at runtime because we didn't have to chase down the > > super classes and their styles. But customers really complained because > if > > you subclassed Button and made a MyButton, you had to know which styles > to > > copy to a MyButton type selector or the component wouldn't work. I'm > sure > > our documentation was not sufficient, but even then, folks thought it was > > a pain. > > > > If you want to ensure no styles are specified in code for the MDL library > > feel free to do so. I'm just not sure how important tat is for the Basic > > set. > > > > > > > >> Similarly, Label isn't supposed to be interactive, so we turn off > mouse > > >> events. It is the equivalent of mouseEnabled in SWF. The
Re: [FlexJS] (Att: Peter Ent) Get rid of extra divs layers we don't want (was Re: [FlexJS]Layout problems)
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] get rid of inline styles (was Re: [FlexJS]Layout problems)
Alex's first point about using the same beads, but not subclassing sounds cleaner to me, Carlos. Kind of the same idea from the other day where all components should be possible to recreate from UIBase with the right set of beads. You should consider trying that out for MDL. - Josh On Dec 1, 2016 11:09 PM, "Alex Harui" wrote: > Re-ordering your post so I can address higher-level points first: > > > On 12/1/16, 4:55 PM, "carlos.rov...@gmail.com on behalf of Carlos Rovira" > wrote: > > > >But Basic set is at the core of > >all. Is at the core of MDL set > > > > > > This statement doesn't have to be true, and makes me think that the old > Flex SDK mentality is persisting. IMO, the MDL set has no obligation to > subclass the Basic set. The top-level components in the Basic set are > supposed to be compositions of beads. MDL can just compose the same or > different beads without having to subclass Basic components. > > One of the problems of having a core and inheritance is that you have to > get it right, but often there isn't one right answer. > > >I think > >Basic set (as is) will not be used at all since the final visuals are not > >production ready, so you know people will need this level of customization > >or they will never join FleJS for sure. and here you have the first > >example of many > >of the styles in flexjs needs to be removed in order to get the MDL branch > >working ok, and so will happen with others like Bootstrap, and so on... > >Only if we create our own FlexJS style design could take into account the > >actual styles, but I think that if MDL or Bootstrap does not need all of > >that, we should not need creating our own CSS set in the end (I can't say > >much more here since I'm not a CSS expert to affirm that, but based on > >what > >I see...is clear that it's the reality). > > > > In my mind, there are going to be two kinds of themes: pre-existing ones > like MDL and custom ones like the themes that regular Flex SDK customers > used to brand their applications. In the second kind, I don't think it > matters as much as to what default styles are. Folks will simply override > the defaults in their themes. > > I was a bit surprised that MDL didn't override everything we set as > defaults for HTML.swc. That means to me that if someone has certain > styles set elsewhere, even in their browser settings, that could cause > really strange and unexpected results. But OK, that's the way it is, and > so we should think of other ways to have a default look for HTML.swc, > although again, as I said above, the MDL library has no obligation to > inherit from HTML.swc. > > If we really need to support more inheritance, then maybe all visual > styles should be moved from HTML into some default theme. It would be > nice to have a better set of defaults that are a bit more production ready > for Basic so we can see how and why there are collisions between themes. > > >You could as well use documentation to expose requirements and make people > >know that 2 or 3 styles are required and if they remove from CSS things > >could break. We could prepare as well a MVCSS (minimum viable CSS) so > >people would not need to use the remove default compiler flag, and have > >another with relative positions, borders and other no-so required things, > >but needed in basic comp set. > > > > > > Way back in early Flex, we found our customers didn't like this. There > was a version of Flex where only the type-selectors with the same name as > the component was applied. So CheckBox extended Button and lots of styles > important to Button needed to be copied to the CheckBox type selector. > This was way faster at runtime because we didn't have to chase down the > super classes and their styles. But customers really complained because if > you subclassed Button and made a MyButton, you had to know which styles to > copy to a MyButton type selector or the component wouldn't work. I'm sure > our documentation was not sufficient, but even then, folks thought it was > a pain. > > If you want to ensure no styles are specified in code for the MDL library > feel free to do so. I'm just not sure how important tat is for the Basic > set. > > > > >> Similarly, Label isn't supposed to be interactive, so we turn off mouse > >> events. It is the equivalent of mouseEnabled in SWF. The way we found > >>to > >> do it is to set a style. Again, I'm not sure that should be settable > >>in a > >> CSS theme. > >> > >> > >I think so. If we could set the style in CSS and we are not doing this > >because we are afraid of our user...that's a very bad policy. There's > >other > >methods to avoid that. For example, if in MDL mouseEnabled is not > >contemplated...I would left in my CSS. > > > > > > > >> The way we handle visible=false also sets a style: display:none. > > > > > >that's one of the styles I historically use when doing some html, and > >always put in CSS...there's no reason not doing the same in FlexJS > >moreover > >tak
Re: [FlexJS] (Att: Peter Ent) Get rid of extra divs layers we don't want (was Re: [FlexJS]Layout problems)
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] get rid of inline styles (was Re: [FlexJS]Layout problems)
Re-ordering your post so I can address higher-level points first: On 12/1/16, 4:55 PM, "carlos.rov...@gmail.com on behalf of Carlos Rovira" wrote: > >But Basic set is at the core of >all. Is at the core of MDL set > > This statement doesn't have to be true, and makes me think that the old Flex SDK mentality is persisting. IMO, the MDL set has no obligation to subclass the Basic set. The top-level components in the Basic set are supposed to be compositions of beads. MDL can just compose the same or different beads without having to subclass Basic components. One of the problems of having a core and inheritance is that you have to get it right, but often there isn't one right answer. >I think >Basic set (as is) will not be used at all since the final visuals are not >production ready, so you know people will need this level of customization >or they will never join FleJS for sure. and here you have the first >example of many >of the styles in flexjs needs to be removed in order to get the MDL branch >working ok, and so will happen with others like Bootstrap, and so on... >Only if we create our own FlexJS style design could take into account the >actual styles, but I think that if MDL or Bootstrap does not need all of >that, we should not need creating our own CSS set in the end (I can't say >much more here since I'm not a CSS expert to affirm that, but based on >what >I see...is clear that it's the reality). > In my mind, there are going to be two kinds of themes: pre-existing ones like MDL and custom ones like the themes that regular Flex SDK customers used to brand their applications. In the second kind, I don't think it matters as much as to what default styles are. Folks will simply override the defaults in their themes. I was a bit surprised that MDL didn't override everything we set as defaults for HTML.swc. That means to me that if someone has certain styles set elsewhere, even in their browser settings, that could cause really strange and unexpected results. But OK, that's the way it is, and so we should think of other ways to have a default look for HTML.swc, although again, as I said above, the MDL library has no obligation to inherit from HTML.swc. If we really need to support more inheritance, then maybe all visual styles should be moved from HTML into some default theme. It would be nice to have a better set of defaults that are a bit more production ready for Basic so we can see how and why there are collisions between themes. >You could as well use documentation to expose requirements and make people >know that 2 or 3 styles are required and if they remove from CSS things >could break. We could prepare as well a MVCSS (minimum viable CSS) so >people would not need to use the remove default compiler flag, and have >another with relative positions, borders and other no-so required things, >but needed in basic comp set. > > Way back in early Flex, we found our customers didn't like this. There was a version of Flex where only the type-selectors with the same name as the component was applied. So CheckBox extended Button and lots of styles important to Button needed to be copied to the CheckBox type selector. This was way faster at runtime because we didn't have to chase down the super classes and their styles. But customers really complained because if you subclassed Button and made a MyButton, you had to know which styles to copy to a MyButton type selector or the component wouldn't work. I'm sure our documentation was not sufficient, but even then, folks thought it was a pain. If you want to ensure no styles are specified in code for the MDL library feel free to do so. I'm just not sure how important tat is for the Basic set. > >> Similarly, Label isn't supposed to be interactive, so we turn off mouse >> events. It is the equivalent of mouseEnabled in SWF. The way we found >>to >> do it is to set a style. Again, I'm not sure that should be settable >>in a >> CSS theme. >> >> >I think so. If we could set the style in CSS and we are not doing this >because we are afraid of our user...that's a very bad policy. There's >other >methods to avoid that. For example, if in MDL mouseEnabled is not >contemplated...I would left in my CSS. > > > >> The way we handle visible=false also sets a style: display:none. > > >that's one of the styles I historically use when doing some html, and >always put in CSS...there's no reason not doing the same in FlexJS >moreover >taking into account this is a framework to craft things and nothing final. IMO, there are styles that are functional like display:none and pointer-events and no-wrap and styles that are visual. For functional styles, I'm not sure it is the easiest API to make folks work with all of these CSS styles instead of through properties on the component, especially properties that have a high likelihood of changing at runtime. So that's why Basic has a visible and alpha properties. Seems nicer to set those than have to set styl
Re: [FlexJS] get rid of inline styles (was Re: [FlexJS]Layout problems)
On Thu, Dec 1, 2016 at 4:55 PM, Carlos Rovira wrote: > > I wish I could agree, but I don't think I can. IMO, some component > > features can only be implemented by setting style properties. In the > > example above, to keep Label as single-line (so you don't have to us > > > and can just use space), we must set white-space:no-wrap. Allowing folks > > to tweak things like that in the CSS seems dangerous to me. > > > > > But, this is user choice. If I stick with styles in css, or I want some of > it, I'm free to keep them or remove for my > use case. keeping It hard-code to avoid people that don't want that be > forced to use is very bad policy IMHO. > > You could as well use documentation to expose requirements and make people > know that 2 or 3 styles are required and if they remove from CSS things > could break. We could prepare as well a MVCSS (minimum viable CSS) so > people would not need to use the remove default compiler flag, and have > another with relative positions, borders and other no-so required things, > but needed in basic comp set. > Some component developers use the *!important *rule to 'protect' their carefully constructed css classes. https://css-tricks.com/when-using-important-is-the-right-choice/#article-header-id-0 > > > > > Similarly, Label isn't supposed to be interactive, so we turn off mouse > > events. It is the equivalent of mouseEnabled in SWF. The way we found > to > > do it is to set a style. Again, I'm not sure that should be settable in > a > > CSS theme. > > > > > I think so. If we could set the style in CSS and we are not doing this > because we are afraid of our user...that's a very bad policy. There's other > methods to avoid that. For example, if in MDL mouseEnabled is not > contemplated...I would left in my CSS. > > > > > The way we handle visible=false also sets a style: display:none. > > > that's one of the styles I historically use when doing some html, and > always put in CSS...there's no reason not doing the same in FlexJS moreover > taking into account this is a framework to craft things and nothing final. > > > > > > But position is a tricky and separate topic. Someone needs to prove that > > none of the examples break if we don't set position to relative or > > absolute the way we do it now. > > > Right, If I'd make the changes I would have to test examples as I move > things from code to CSS. and if something can not be done left untouched or > until we get a way to do it. > > > > The comment in Container.as says: > > > > // absolute positioned children need a non-null > > // position value in the parent. It might > > // get set to 'absolute' if the container is > > // also absolutely positioned > > > > So that implies that if you put a child in a Container and set its x or y > > value, it won't work unless we set position to absolute or relative. > > That's making me think that the test case is a nested set of Containers > > with a child in the inner container with x,y position. > > > Right, but again that's in the people using the basic set, and not for > potential user that will want to use FlexJS for their own use cases. > > We are setting the basis of the technology. The building blocks. And as > building block, those should come free of charges. > > I'm creating MDL only to show people some beautiful FlexJS screens that > make people jump (since people buys for what they see more quick and I > think this is a urgent need for us right now)...but I assume that few > people will end using that (I think) and will want to customize more their > experiences. Maybe I could expect 5%-15%...people using MDL set? I think > Basic set (as is) will not be used at all since the final visuals are not > production ready, so you know people will need this level of customization > or they will never join FleJS for sure. But Basic set is at the core of > all. Is at the core of MDL set and here you have the first example of many > of the styles in flexjs needs to be removed in order to get the MDL branch > working ok, and so will happen with others like Bootstrap, and so on... > Only if we create our own FlexJS style design could take into account the > actual styles, but I think that if MDL or Bootstrap does not need all of > that, we should not need creating our own CSS set in the end (I can't say > much more here since I'm not a CSS expert to affirm that, but based on what > I see...is clear that it's the reality). > > > > -- > Carlos Rovira > http://about.me/carlosrovira >
Re: [FlexJS] get rid of inline styles (was Re: [FlexJS]Layout problems)
> I wish I could agree, but I don't think I can. IMO, some component > features can only be implemented by setting style properties. In the > example above, to keep Label as single-line (so you don't have to us > and can just use space), we must set white-space:no-wrap. Allowing folks > to tweak things like that in the CSS seems dangerous to me. > > But, this is user choice. If I stick with styles in css, or I want some of it, I'm free to keep them or remove for my use case. keeping It hard-code to avoid people that don't want that be forced to use is very bad policy IMHO. You could as well use documentation to expose requirements and make people know that 2 or 3 styles are required and if they remove from CSS things could break. We could prepare as well a MVCSS (minimum viable CSS) so people would not need to use the remove default compiler flag, and have another with relative positions, borders and other no-so required things, but needed in basic comp set. > Similarly, Label isn't supposed to be interactive, so we turn off mouse > events. It is the equivalent of mouseEnabled in SWF. The way we found to > do it is to set a style. Again, I'm not sure that should be settable in a > CSS theme. > > I think so. If we could set the style in CSS and we are not doing this because we are afraid of our user...that's a very bad policy. There's other methods to avoid that. For example, if in MDL mouseEnabled is not contemplated...I would left in my CSS. > The way we handle visible=false also sets a style: display:none. that's one of the styles I historically use when doing some html, and always put in CSS...there's no reason not doing the same in FlexJS moreover taking into account this is a framework to craft things and nothing final. > > But position is a tricky and separate topic. Someone needs to prove that > none of the examples break if we don't set position to relative or > absolute the way we do it now. Right, If I'd make the changes I would have to test examples as I move things from code to CSS. and if something can not be done left untouched or until we get a way to do it. > The comment in Container.as says: > > // absolute positioned children need a non-null > // position value in the parent. It might > // get set to 'absolute' if the container is > // also absolutely positioned > > So that implies that if you put a child in a Container and set its x or y > value, it won't work unless we set position to absolute or relative. > That's making me think that the test case is a nested set of Containers > with a child in the inner container with x,y position. Right, but again that's in the people using the basic set, and not for potential user that will want to use FlexJS for their own use cases. We are setting the basis of the technology. The building blocks. And as building block, those should come free of charges. I'm creating MDL only to show people some beautiful FlexJS screens that make people jump (since people buys for what they see more quick and I think this is a urgent need for us right now)...but I assume that few people will end using that (I think) and will want to customize more their experiences. Maybe I could expect 5%-15%...people using MDL set? I think Basic set (as is) will not be used at all since the final visuals are not production ready, so you know people will need this level of customization or they will never join FleJS for sure. But Basic set is at the core of all. Is at the core of MDL set and here you have the first example of many of the styles in flexjs needs to be removed in order to get the MDL branch working ok, and so will happen with others like Bootstrap, and so on... Only if we create our own FlexJS style design could take into account the actual styles, but I think that if MDL or Bootstrap does not need all of that, we should not need creating our own CSS set in the end (I can't say much more here since I'm not a CSS expert to affirm that, but based on what I see...is clear that it's the reality). -- 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)
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] get rid of inline styles (was Re: [FlexJS]Layout problems)
On 12/1/16, 4:01 PM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
wrote:
>to separate things:
>
>Such as? Depending on your layout, left, top, width, and height will be
>> set in CSS. In UIBase, setting the x value sets style.left, etc. If
>> there is an alternative, please let me know what it is.
>> -Alex
>>
>>
>I get this:
>
>some texttype="button" class="TextButton" style="position: relative;">a
>button
>
>from this:
>
>
>
>
>
Ah, ok, I didn't understand what you meant by "kilometric".
>
>in my MDLExample (take into account that I use exclude default CSS
>compiler
>param)
>
>So as you see there's lots of "style" properties above that should not be.
>
>The right output should be:
>
>some textclass="TextButton">a button
>
>So as I use compiler option exclude default css file I ensure my app only
>has the css I put, and not carry anything I don't want.
>
>
>why this is happen? To take only one example. In js:Container line 104
>there's:
>
>positioner.style.position = 'relative';
>
>this should remove from there and put in defaults.css line 93
>
>Container
>{
> position = 'relative';
>
>
>
>Do you agree with that?
I wish I could agree, but I don't think I can. IMO, some component
features can only be implemented by setting style properties. In the
example above, to keep Label as single-line (so you don't have to us
and can just use space), we must set white-space:no-wrap. Allowing folks
to tweak things like that in the CSS seems dangerous to me.
Similarly, Label isn't supposed to be interactive, so we turn off mouse
events. It is the equivalent of mouseEnabled in SWF. The way we found to
do it is to set a style. Again, I'm not sure that should be settable in a
CSS theme.
The way we handle visible=false also sets a style: display:none. And as I
mentioned, setting x,y,width,height also set style properties, so I think
it is ok for style properties to be set in component code.
I would agree that most or maybe all style properties that affect the
visuals (border, padding, margin, color, fonts) should not be set in
component code and only via defaults.css.
But position is a tricky and separate topic. Someone needs to prove that
none of the examples break if we don't set position to relative or
absolute the way we do it now. The comment in Container.as says:
// absolute positioned children need a non-null
// position value in the parent. It might
// get set to 'absolute' if the container is
// also absolutely positioned
So that implies that if you put a child in a Container and set its x or y
value, it won't work unless we set position to absolute or relative.
That's making me think that the test case is a nested set of Containers
with a child in the inner container with x,y position. IIRC, having
BasicLayout which supports x,y values set the position style on the
Container isn't good enough. Maybe it needs to walk the parent chain and
set position an all parents, but that seems dangerous as well. If you
have time to test that out and propose a better solution, that would be
great.
Thanks,
-Alex
[FlexJS] (Att: Peter Ent) Get rid of extra divs layers we don't want (was Re: [FlexJS]Layout problems)
> > 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
[FlexJS] get rid of inline styles (was Re: [FlexJS]Layout problems)
to separate things:
Such as? Depending on your layout, left, top, width, and height will be
> set in CSS. In UIBase, setting the x value sets style.left, etc. If
> there is an alternative, please let me know what it is.
> -Alex
>
>
I get this:
some texta
button
from this:
in my MDLExample (take into account that I use exclude default CSS compiler
param)
So as you see there's lots of "style" properties above that should not be.
The right output should be:
some texta button
So as I use compiler option exclude default css file I ensure my app only
has the css I put, and not carry anything I don't want.
why this is happen? To take only one example. In js:Container line 104
there's:
positioner.style.position = 'relative';
this should remove from there and put in defaults.css line 93
Container
{
position = 'relative';
Do you agree with that?
I could do that refactor if you want
--
Carlos Rovira
http://about.me/carlosrovira
Re: [FlexJS]Layout problems
On 12/1/16, 2:43 PM, "carlos.rov...@gmail.com on behalf of Carlos Rovira" wrote: >> Can you be more specific? I thought most components were picking up all >> of their styles from defaults.css. Which components aren't doing this? >> >> >Most used like Container, Label or Button not. If you check html output >you >will see kilometric properties assigned to style attribute. Such as? Depending on your layout, left, top, width, and height will be set in CSS. In UIBase, setting the x value sets style.left, etc. If there is an alternative, please let me know what it is. > > >> I don't remember if this is the main reason we have to propagate >>relative >> or absolute positioning in order to get percentages to work >>"everywhere", >> but these are the kinds of issues we faced. Folks are welcome to test >>out >> different implementations on the examples. >> >> >As I said, for my is ok the actual "styling" in basic HTML.swc set, >BUT...only if all style code is pass to CSS so I and others could remove >when use in our own projects. If not it will be unusable for everybody >since no body would want a , i.e: border:2px in js:List or other hardcode >styles in basic components. Ergo, my bet is that all people would exclude >default html swc CSS. The default.css for the HTML should set reasonable defaults for a default theme that only uses bare HTMLElements. I'd love to have someone with better design skills figure out that default look. But when switching to another theme like MDL or Flat, you are correct that most of the default styles from HTML should not be carried over. I had assumed the themes would override every default in defaults.css, but they don't so that's why we added the option to exclude the defaults. There might be a better way to manage this. I'm open to ideas. > > >> So most recently, Peter changed MXMLItemRenderer to get rid of its inner >> content area and just be more like the lightweight Container that Harbs >> mentioned earlier in this thread. We could make that the default >> Container and have a ContainerWIthNonCSSChrome that has the inner >> contentArea and Panel could extend that. >> >> >Alex all I need is a pointer to the code that make the removal of the >middle div. >Could you share that? FWIW, List is not a Container because it doesn't take an arbitrary set of children. It is a control. It has a similar topology to a Container and the ListView extends ContainerView, but isn't a Container. 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
Re: [FlexJS]Layout problems
> Can you be more specific? I thought most components were picking up all > of their styles from defaults.css. Which components aren't doing this? > > Most used like Container, Label or Button not. If you check html output you will see kilometric properties assigned to style attribute. > I don't remember if this is the main reason we have to propagate relative > or absolute positioning in order to get percentages to work "everywhere", > but these are the kinds of issues we faced. Folks are welcome to test out > different implementations on the examples. > > As I said, for my is ok the actual "styling" in basic HTML.swc set, BUT...only if all style code is pass to CSS so I and others could remove when use in our own projects. If not it will be unusable for everybody since no body would want a , i.e: border:2px in js:List or other hardcode styles in basic components. Ergo, my bet is that all people would exclude default html swc CSS. > So most recently, Peter changed MXMLItemRenderer to get rid of its inner > content area and just be more like the lightweight Container that Harbs > mentioned earlier in this thread. We could make that the default > Container and have a ContainerWIthNonCSSChrome that has the inner > contentArea and Panel could extend that. > > Alex all I need is a pointer to the code that make the removal of the middle div. Could you share that? I think an example of this is worth the time invested since Harbs and me could continue our own paths evolving it. But my problem is that (at least me) I'm not able to find the ways to get in (i.e List): (List container) (item) (item) I always get: (List container) (ListView container). <-- all I want is get rid of this (and if I understood right this is done by ListView) (item) (item) > Thoughts? > -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]Layout problems
On 12/1/16, 1:57 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira" wrote: > >In MDL we don't need any style tag and percents works ok. But if I use >some >HTML.swc comps I get the styles bloating my html and I don't want that. So >for that reason I think we should refactor styles to CSS. As well this is >a >basic separation of concerns and we should avoid that always as a golden >rule. Can you be more specific? I thought most components were picking up all of their styles from defaults.css. Which components aren't doing this? > >Another problem is that sometimes we get div inside div (or other tags) >that we don't need. I already don't know how to get rid of this. I think >is >VIEW comps what make that magic, but I'd need some example to see how it >works (for example my problems with List that I need to solve). Peter just spend some time on this. Historically, we wanted Container to be able to generalize to create a Panel. It could be we haven't designed Panel properly, but AFAICT, the TitleBar for a Panel isn't describable in CSS. It is really an additional content area and offsets the y position of the children of the Panel. So, having a contentArea allows for non-CSS chrome, and makes it easier to manage x,y without doing translations on every read/write. IOW, it wouldn't be any fun if, in order to place a component in the upper left of a panel you couldn't just set y=0, but had to set y to titleBar.height. I don't remember if this is the main reason we have to propagate relative or absolute positioning in order to get percentages to work "everywhere", but these are the kinds of issues we faced. Folks are welcome to test out different implementations on the examples. So most recently, Peter changed MXMLItemRenderer to get rid of its inner content area and just be more like the lightweight Container that Harbs mentioned earlier in this thread. We could make that the default Container and have a ContainerWIthNonCSSChrome that has the inner contentArea and Panel could extend that. Thoughts? -Alex
Re: [FlexJS]Layout problems
If a VIEW bead could solve that problem and remove the nested div, that would be right for me...but we need some working example and a description of how to make that. With js:List I was searching without luck how to remove the extra div layer 2016-12-01 11:12 GMT+01:00 Harbs : > That’s something I alluded to in my post. > > Container components have double divs to accommodate View and (scroll > viewports?). I don’t think this is generally needed in HTML and I think it > causes more problems than it solves. There should probably be “lightweight” > Container and “heavyweight” Container if it’s necessary. > > On Dec 1, 2016, at 11:57 AM, Carlos Rovira > wrote: > > > Another problem is that sometimes we get div inside div (or other tags) > > that we don't need. I already don't know how to get rid of this. I think > is > > VIEW comps what make that magic, but I'd need some example to see how it > > works (for example my problems with List that I need to solve). > > -- 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]Layout problems
That’s something I alluded to in my post. Container components have double divs to accommodate View and (scroll viewports?). I don’t think this is generally needed in HTML and I think it causes more problems than it solves. There should probably be “lightweight” Container and “heavyweight” Container if it’s necessary. On Dec 1, 2016, at 11:57 AM, Carlos Rovira wrote: > Another problem is that sometimes we get div inside div (or other tags) > that we don't need. I already don't know how to get rid of this. I think is > VIEW comps what make that magic, but I'd need some example to see how it > works (for example my problems with List that I need to solve).
Re: [FlexJS]Layout problems
Hi, just to add something more here. I already mentioned the problems of div relative positioning in other threads. I as well think that having the basic set with predefined styles is not PAYG, and we get a bloated html full of tags with style attributes (div, span...). The problem Alex comment in the other thread was that percentages was not playing well. That's a problem, but maybe one option would be to remove all styles tags in createElement (or other AS code) and move to CSS. In this way you can exclude in your project and remove the rules from the basic set. That's what I do with MDL. In MDL we don't need any style tag and percents works ok. But if I use some HTML.swc comps I get the styles bloating my html and I don't want that. So for that reason I think we should refactor styles to CSS. As well this is a basic separation of concerns and we should avoid that always as a golden rule. In resume, we should get rid of all "styles" set in code that translates to output html tags in order to be able to be easy to exclude if you don't want, or don't like and want another. Another problem is that sometimes we get div inside div (or other tags) that we don't need. I already don't know how to get rid of this. I think is VIEW comps what make that magic, but I'd need some example to see how it works (for example my problems with List that I need to solve). 2016-11-27 16:12 GMT+01:00 Harbs : > I’m not blaming the concepts. I’m just stating that as it stands, layout > is really hard. > > Part of the problem I was able to see was due to the fact that there were > nested divs with alternating absolute and relative positioning. This killed > all padding settings to the sub-objects. Basically the default layout was > preventing natural browser positioning. (anti-PAYG) ;-) > > Maybe the solution is to write another layout, but I have a feeling that > simplifying the layout might help even more. > > Yishay and I will try to put together some test cases to help show the > problems and possibly help find the correct solution... > > On Nov 27, 2016, at 5:06 PM, Alex Harui wrote: > > > > > > > On 11/27/16, 3:31 AM, "Harbs" wrote: > > > >> FlexJS makes it way too hard to solve simple layout challenges. > > > > I don't know if it is fair to blame the patterns and principles of FlexJS > > for that, but it certainly is possible that the Layout you need hasn't > > been written yet. > > > > Keep in mind that regular Flex VerticalLayout visited every child twice > > and used %width in a non-CSS-compliant way. So under PAYG, the default > > FlexJS VerticalLayout is going to leverage what the browser will do and > > work differently. > > > > But that means these lighter weight layouts will leverage CSS and > > StackOverflow is full of folks wrestling with CSS to get what they want. > > If FlexJS has other, slower layouts that solve these common problems, > that > > will be an advantage for us. > > > > The way I suggest folks deal with layout right now (given that the layout > > you want may not exist yet), is to just use an HTML editor to layout some > > widgets in the way you want. All FlexJS is trying to do is identify and > > encapsulate existing HTML and JS patterns and present them as components. > > So figure out what the HTML needs to look like and that will determine if > > an existing layout can do it, or if you need to write a new one. Don't > > forget that in FlexJS, there is both CSS margin and padding: regular > Flex > > only supported padding and a non-CSS compliant "gap". > > > > Thanks, > > -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]Layout problems
I’m not blaming the concepts. I’m just stating that as it stands, layout is really hard. Part of the problem I was able to see was due to the fact that there were nested divs with alternating absolute and relative positioning. This killed all padding settings to the sub-objects. Basically the default layout was preventing natural browser positioning. (anti-PAYG) ;-) Maybe the solution is to write another layout, but I have a feeling that simplifying the layout might help even more. Yishay and I will try to put together some test cases to help show the problems and possibly help find the correct solution... On Nov 27, 2016, at 5:06 PM, Alex Harui wrote: > > > On 11/27/16, 3:31 AM, "Harbs" wrote: > >> FlexJS makes it way too hard to solve simple layout challenges. > > I don't know if it is fair to blame the patterns and principles of FlexJS > for that, but it certainly is possible that the Layout you need hasn't > been written yet. > > Keep in mind that regular Flex VerticalLayout visited every child twice > and used %width in a non-CSS-compliant way. So under PAYG, the default > FlexJS VerticalLayout is going to leverage what the browser will do and > work differently. > > But that means these lighter weight layouts will leverage CSS and > StackOverflow is full of folks wrestling with CSS to get what they want. > If FlexJS has other, slower layouts that solve these common problems, that > will be an advantage for us. > > The way I suggest folks deal with layout right now (given that the layout > you want may not exist yet), is to just use an HTML editor to layout some > widgets in the way you want. All FlexJS is trying to do is identify and > encapsulate existing HTML and JS patterns and present them as components. > So figure out what the HTML needs to look like and that will determine if > an existing layout can do it, or if you need to write a new one. Don't > forget that in FlexJS, there is both CSS margin and padding: regular Flex > only supported padding and a non-CSS compliant "gap". > > Thanks, > -Alex >
Re: [FlexJS]Layout problems
On 11/27/16, 3:31 AM, "Harbs" wrote: >FlexJS makes it way too hard to solve simple layout challenges. I don't know if it is fair to blame the patterns and principles of FlexJS for that, but it certainly is possible that the Layout you need hasn't been written yet. Keep in mind that regular Flex VerticalLayout visited every child twice and used %width in a non-CSS-compliant way. So under PAYG, the default FlexJS VerticalLayout is going to leverage what the browser will do and work differently. But that means these lighter weight layouts will leverage CSS and StackOverflow is full of folks wrestling with CSS to get what they want. If FlexJS has other, slower layouts that solve these common problems, that will be an advantage for us. The way I suggest folks deal with layout right now (given that the layout you want may not exist yet), is to just use an HTML editor to layout some widgets in the way you want. All FlexJS is trying to do is identify and encapsulate existing HTML and JS patterns and present them as components. So figure out what the HTML needs to look like and that will determine if an existing layout can do it, or if you need to write a new one. Don't forget that in FlexJS, there is both CSS margin and padding: regular Flex only supported padding and a non-CSS compliant "gap". Thanks, -Alex
