Peter Ent's emails being flagged

[Dave Glasser <dg...@pobox.com>]

I use Yahoo email, and it seems that the majority of Peter Ent's (and others from this list) get routed into my spam folder. Marking the flagged messages as "Not Spam" seems to have no effect on subsequent mails.
Is anyone else experiencing this with Yahoo email?


      From: Peter Ent <pe...@adobe.com>
 To: "dev@flex.apache.org" <de...@flex.apache.org> 
 Sent: Thursday, March 23, 2017 1:44 PM
 Subject: [FlexJS] Summary of Changes
   
FlexJS Container and Layout Upgrade

My goal when starting this process was to have FlexJS produce leaner HTML structures and to reduce the amount of JavaScript code getting cross-compiled. My latest commit does the following:

- Produces simpler HTML structures for the container classes, Group, Container, and Panel.
- Simplifies a number of the layout classes for JS while fixing or tuning the SWF code to mimic the browser.
- Moves code that only affects the SWF side into SWF code blocks.

I touched only Core and HTML projects and fixed Effects so it would compile since it had the fewest issues. MDL and Charts have larger concerns and I hope to sort those out as quickly as I can.

Here are the classes and changes you will find:

Group: This new class (introduced in a previous commit) produces the simplest container for HTML (it is just a DIV) and SWF. By default it provides no layout in case you want to style in completely using CSS. Group (and its view bead, GroupView), are the foundation of the container classes. Group runs a layout bead (if there is one) and handles the sizing of elements on the SWF side. The JS side is left alone for the browser to manage (this was the biggest change).

Container: This class, which extends Group, exists to provide scrolling on the SWF side. The JS side of Container is very light adds little to what Group does. On the SWF side, Container is a nested structure in order to providing content masking and scrolling (which is handled on the JS side by using overflow:auto style, which is all the ScrollingViewport bead will do if you add it to Container).

UIBase: The major change to UIBase is that it no longer sets the position style. That means if you set the x and y properties of a component, it will, on the JS side, only set the left and top style values. If you intend to place elements at specific pixel coordinates, use a container (Group or Container) with BasicLayout which will add position:absolute style to all of the children.

NOTE: I made UIBase (and a couple other classes, too) not set position style because I saw how easily that caused other problems, especially when there was a mixing of "absolute" and "relative" position values. Now that this work is done, it may not be a bad thing to have UIBase's x and y properties set position:absolute has a convenience. It does however, have some ramifications; if you have position:absolute that will override pretty much all of the layout types. But maybe the developer just sees this and stops setting x and y. Also, there is no way to unset position once set. These are things we will have to see how they play out.

Layouts: The layouts no longer change the size of their container hosts nor do they produce the "layoutComplete" event. The GroupView class handles both of these now to make the process of layout and sizing/positioning consistent.

Lists: The DataGroup that lists use to hold the item renderers is no longer in play. The DataGroup caused unnecessary nesting of elements (DIV inside of DIV). To break that, components like List had to become their own item renderer parents. Squaring this away is perhaps the biggest challenge since a number of complex components use List as their base. The DataContainer is now the basis for lists, with List being its first subclass since they have so much in common. The DataContainerView bead is now the basis for all list views.

Panel: The Panel is now an extension of Group and it contains three children: a TitleBar, a ControlBar (for PanelWithControlBar), and a Container for the content space. When you do: panel.addElement(object), the Panel code redirects this to its Container child. Similarly, panel.numElements tells you the number of elements in the Container child. Because Panel is now a Group (so are TitleBar and ControlBar), it uses a layout to size and position those three children. When you build your own components, you can use Group + layout to achieve the look you want with minimal HTML structure.

Interfaces: There are couple of key changes to interfaces. First, there is a new interface in the Core project: ILayoutView. This interface is implemented by any component whose children can be manipulated by a layout. The ILayoutHost interface's function, contentView, has been changed to return an instance of ILayoutView. The functions listed in ILayoutView may be expanded if we run into situations or layouts that need more information from their layout parents; this change is probably the source of most compilation issues you will see.

Using Layouts inside of Components: As stated above, Panel (and PanelWithControlBar), now uses a layout for its own purposes. This is the VerticalFlexLayout, modeled on the HTML/CSS Flexbox. This general purpose CSS creation makes the code much simpler and cleaner. Basically, the JS layout code is a few lines with maybe a loop to set each child's display correctly. The SWF side then has the task to mimic the layout. I have not completed the transition on all of the layouts, but the common ones have tested correctly.

Regards,
Peter Ent
Adobe Systems/Apache Flex Project


   

Re: Peter Ent's emails being flagged

[Carlos Rovira <ca...@codeoscopic.com>]

I got some emails again in February routed to spam, then I march it went to
inbox normaly.
Very strange behaviour...

2017-03-24 16:35 GMT+01:00 Alex Harui <ah...@adobe.com>:

> Carlos had a problem with Peter's email in January.  I'm not sure what the
> answer is.
>
> -Alex
>
> On 3/24/17, 7:54 AM, "Dave Glasser" <dg...@pobox.com> wrote:
>
> >I use Yahoo email, and it seems that the majority of Peter Ent's (and
> >others from this list) get routed into my spam folder. Marking the
> >flagged messages as "Not Spam" seems to have no effect on subsequent
> >mails.
> >Is anyone else experiencing this with Yahoo email?
> >
> >
> >      From: Peter Ent <pe...@adobe.com>
> > To: "dev@flex.apache.org" <de...@flex.apache.org>
> > Sent: Thursday, March 23, 2017 1:44 PM
> > Subject: [FlexJS] Summary of Changes
> >
> >FlexJS Container and Layout Upgrade
> >
> >My goal when starting this process was to have FlexJS produce leaner HTML
> >structures and to reduce the amount of JavaScript code getting
> >cross-compiled. My latest commit does the following:
> >
> >- Produces simpler HTML structures for the container classes, Group,
> >Container, and Panel.
> >- Simplifies a number of the layout classes for JS while fixing or tuning
> >the SWF code to mimic the browser.
> >- Moves code that only affects the SWF side into SWF code blocks.
> >
> >I touched only Core and HTML projects and fixed Effects so it would
> >compile since it had the fewest issues. MDL and Charts have larger
> >concerns and I hope to sort those out as quickly as I can.
> >
> >Here are the classes and changes you will find:
> >
> >Group: This new class (introduced in a previous commit) produces the
> >simplest container for HTML (it is just a DIV) and SWF. By default it
> >provides no layout in case you want to style in completely using CSS.
> >Group (and its view bead, GroupView), are the foundation of the container
> >classes. Group runs a layout bead (if there is one) and handles the
> >sizing of elements on the SWF side. The JS side is left alone for the
> >browser to manage (this was the biggest change).
> >
> >Container: This class, which extends Group, exists to provide scrolling
> >on the SWF side. The JS side of Container is very light adds little to
> >what Group does. On the SWF side, Container is a nested structure in
> >order to providing content masking and scrolling (which is handled on the
> >JS side by using overflow:auto style, which is all the ScrollingViewport
> >bead will do if you add it to Container).
> >
> >UIBase: The major change to UIBase is that it no longer sets the position
> >style. That means if you set the x and y properties of a component, it
> >will, on the JS side, only set the left and top style values. If you
> >intend to place elements at specific pixel coordinates, use a container
> >(Group or Container) with BasicLayout which will add position:absolute
> >style to all of the children.
> >
> >NOTE: I made UIBase (and a couple other classes, too) not set position
> >style because I saw how easily that caused other problems, especially
> >when there was a mixing of "absolute" and "relative" position values. Now
> >that this work is done, it may not be a bad thing to have UIBase's x and
> >y properties set position:absolute has a convenience. It does however,
> >have some ramifications; if you have position:absolute that will override
> >pretty much all of the layout types. But maybe the developer just sees
> >this and stops setting x and y. Also, there is no way to unset position
> >once set. These are things we will have to see how they play out.
> >
> >Layouts: The layouts no longer change the size of their container hosts
> >nor do they produce the "layoutComplete" event. The GroupView class
> >handles both of these now to make the process of layout and
> >sizing/positioning consistent.
> >
> >Lists: The DataGroup that lists use to hold the item renderers is no
> >longer in play. The DataGroup caused unnecessary nesting of elements (DIV
> >inside of DIV). To break that, components like List had to become their
> >own item renderer parents. Squaring this away is perhaps the biggest
> >challenge since a number of complex components use List as their base.
> >The DataContainer is now the basis for lists, with List being its first
> >subclass since they have so much in common. The DataContainerView bead is
> >now the basis for all list views.
> >
> >Panel: The Panel is now an extension of Group and it contains three
> >children: a TitleBar, a ControlBar (for PanelWithControlBar), and a
> >Container for the content space. When you do: panel.addElement(object),
> >the Panel code redirects this to its Container child. Similarly,
> >panel.numElements tells you the number of elements in the Container
> >child. Because Panel is now a Group (so are TitleBar and ControlBar), it
> >uses a layout to size and position those three children. When you build
> >your own components, you can use Group + layout to achieve the look you
> >want with minimal HTML structure.
> >
> >Interfaces: There are couple of key changes to interfaces. First, there
> >is a new interface in the Core project: ILayoutView. This interface is
> >implemented by any component whose children can be manipulated by a
> >layout. The ILayoutHost interface's function, contentView, has been
> >changed to return an instance of ILayoutView. The functions listed in
> >ILayoutView may be expanded if we run into situations or layouts that
> >need more information from their layout parents; this change is probably
> >the source of most compilation issues you will see.
> >
> >Using Layouts inside of Components: As stated above, Panel (and
> >PanelWithControlBar), now uses a layout for its own purposes. This is the
> >VerticalFlexLayout, modeled on the HTML/CSS Flexbox. This general purpose
> >CSS creation makes the code much simpler and cleaner. Basically, the JS
> >layout code is a few lines with maybe a loop to set each child's display
> >correctly. The SWF side then has the task to mimic the layout. I have not
> >completed the transition on all of the layouts, but the common ones have
> >tested correctly.
> >
> >Regards,
> >Peter Ent
> >Adobe Systems/Apache Flex Project
> >
> >
> >
>
>


-- 

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: Peter Ent's emails being flagged

[Alex Harui <ah...@adobe.com>]

Carlos had a problem with Peter's email in January.  I'm not sure what the
answer is.

-Alex

On 3/24/17, 7:54 AM, "Dave Glasser" <dg...@pobox.com> wrote:

>I use Yahoo email, and it seems that the majority of Peter Ent's (and
>others from this list) get routed into my spam folder. Marking the
>flagged messages as "Not Spam" seems to have no effect on subsequent
>mails.
>Is anyone else experiencing this with Yahoo email?
>
>
>      From: Peter Ent <pe...@adobe.com>
> To: "dev@flex.apache.org" <de...@flex.apache.org>
> Sent: Thursday, March 23, 2017 1:44 PM
> Subject: [FlexJS] Summary of Changes
>   
>FlexJS Container and Layout Upgrade
>
>My goal when starting this process was to have FlexJS produce leaner HTML
>structures and to reduce the amount of JavaScript code getting
>cross-compiled. My latest commit does the following:
>
>- Produces simpler HTML structures for the container classes, Group,
>Container, and Panel.
>- Simplifies a number of the layout classes for JS while fixing or tuning
>the SWF code to mimic the browser.
>- Moves code that only affects the SWF side into SWF code blocks.
>
>I touched only Core and HTML projects and fixed Effects so it would
>compile since it had the fewest issues. MDL and Charts have larger
>concerns and I hope to sort those out as quickly as I can.
>
>Here are the classes and changes you will find:
>
>Group: This new class (introduced in a previous commit) produces the
>simplest container for HTML (it is just a DIV) and SWF. By default it
>provides no layout in case you want to style in completely using CSS.
>Group (and its view bead, GroupView), are the foundation of the container
>classes. Group runs a layout bead (if there is one) and handles the
>sizing of elements on the SWF side. The JS side is left alone for the
>browser to manage (this was the biggest change).
>
>Container: This class, which extends Group, exists to provide scrolling
>on the SWF side. The JS side of Container is very light adds little to
>what Group does. On the SWF side, Container is a nested structure in
>order to providing content masking and scrolling (which is handled on the
>JS side by using overflow:auto style, which is all the ScrollingViewport
>bead will do if you add it to Container).
>
>UIBase: The major change to UIBase is that it no longer sets the position
>style. That means if you set the x and y properties of a component, it
>will, on the JS side, only set the left and top style values. If you
>intend to place elements at specific pixel coordinates, use a container
>(Group or Container) with BasicLayout which will add position:absolute
>style to all of the children.
>
>NOTE: I made UIBase (and a couple other classes, too) not set position
>style because I saw how easily that caused other problems, especially
>when there was a mixing of "absolute" and "relative" position values. Now
>that this work is done, it may not be a bad thing to have UIBase's x and
>y properties set position:absolute has a convenience. It does however,
>have some ramifications; if you have position:absolute that will override
>pretty much all of the layout types. But maybe the developer just sees
>this and stops setting x and y. Also, there is no way to unset position
>once set. These are things we will have to see how they play out.
>
>Layouts: The layouts no longer change the size of their container hosts
>nor do they produce the "layoutComplete" event. The GroupView class
>handles both of these now to make the process of layout and
>sizing/positioning consistent.
>
>Lists: The DataGroup that lists use to hold the item renderers is no
>longer in play. The DataGroup caused unnecessary nesting of elements (DIV
>inside of DIV). To break that, components like List had to become their
>own item renderer parents. Squaring this away is perhaps the biggest
>challenge since a number of complex components use List as their base.
>The DataContainer is now the basis for lists, with List being its first
>subclass since they have so much in common. The DataContainerView bead is
>now the basis for all list views.
>
>Panel: The Panel is now an extension of Group and it contains three
>children: a TitleBar, a ControlBar (for PanelWithControlBar), and a
>Container for the content space. When you do: panel.addElement(object),
>the Panel code redirects this to its Container child. Similarly,
>panel.numElements tells you the number of elements in the Container
>child. Because Panel is now a Group (so are TitleBar and ControlBar), it
>uses a layout to size and position those three children. When you build
>your own components, you can use Group + layout to achieve the look you
>want with minimal HTML structure.
>
>Interfaces: There are couple of key changes to interfaces. First, there
>is a new interface in the Core project: ILayoutView. This interface is
>implemented by any component whose children can be manipulated by a
>layout. The ILayoutHost interface's function, contentView, has been
>changed to return an instance of ILayoutView. The functions listed in
>ILayoutView may be expanded if we run into situations or layouts that
>need more information from their layout parents; this change is probably
>the source of most compilation issues you will see.
>
>Using Layouts inside of Components: As stated above, Panel (and
>PanelWithControlBar), now uses a layout for its own purposes. This is the
>VerticalFlexLayout, modeled on the HTML/CSS Flexbox. This general purpose
>CSS creation makes the code much simpler and cleaner. Basically, the JS
>layout code is a few lines with maybe a loop to set each child's display
>correctly. The SWF side then has the task to mimic the layout. I have not
>completed the transition on all of the layouts, but the common ones have
>tested correctly.
>
>Regards,
>Peter Ent
>Adobe Systems/Apache Flex Project
>
>
>