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 <aha...@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" <dglas...@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 <p...@adobe.com> > > To: "dev@flex.apache.org" <dev@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.
