It should be fairly simple to have ContainerView set up the background if explicit width AND height are set. Given what you said/wrote, this seems to be the best fit. The problem I’ve run into is only an issue for <js:Container width="100" height="100”/>. All other situations shouldn’t produce an empty container space since at least one dimension is sized by content and in that case, as soon as a child is added you see the container.
—peter On 5/19/15, 11:13 AM, "Alex Harui" <aha...@adobe.com> wrote: >Interesting. We could do that, but it bugs me a bit. The deferred >childrenAdded call is intended to close a transaction where addElement >calls were told not to dispatch events on each call. If you look at it >that way, a deferred childrenAdded call is an optimization option also >available to folks just writing code in AS. > >If we make it a required transaction for the creation of a Container then >in AS it means that everybody has to remember to make that call. I’d like >to avoid that requirement if possible. > >If you check out the layout wiki page [1], views like ContainerView should >be checking 3 different scenarios. For an empty container, if sized by >the parent, ContainerView should get an event and then run its view code >which should call the layout code (which would do nothing as there are no >children) then call the background bead. I’m guessing the background bead >may not pick up the right size since nobody has set the size of the >actualParent. If so, ContainerView should be setting the size. > >For a container sized to content, I would argue nothing should show up, or >maybe the size needs to factor in padding. We’d have to see what browsers >do. > >For a container with set dimensions, the ContainerView should be setting >the actualParent’s size and background bead should be drawing accordingly. > So maybe the bug is in there some where. > >Of course, I could be wrong… >-Alex > > >[1] https://cwiki.apache.org/confluence/display/FLEX/FlexJS+Layout > > >On 5/19/15, 7:27 AM, "Peter Ent" <p...@adobe.com> wrote: > >>I¹ve been looking into this. >> >>In MXMLDataInterpreter.generateMXMLInstances, if the data parameter is >>null, the function immediately returns. This means you have something >>like >><js:Container /> - it has no children. >> >>I¹m wondering if a better approach might be to re-write this function as: >> >>public static function generateMXMLInstances(document:Object, >>parent:IParent, data:Array):void >>{ >> if (data) generateMXMLArray(document, parent, data); >> >> // maybe we can remove this. All IContainers should be >>IMXMLDocuments? >> if (parent is IContainer) >> { >> IContainer(parent).childrenAdded(); >> } >>} >> >> >>This way, childrenAdded is called all the time. It would mean that >>zero-or-more children were added vs one-or-more children were added. This >>would allow things that draw backgrounds to be called in a natural way. >>It >>would also mean that code that is optimized to work for one-or-more >>children should first check to see that there are children before >>proceeding. >> >>That do you think? >> >>‹peter >> >>On 5/18/15, 5:11 PM, "Alex Harui" <aha...@adobe.com> wrote: >> >>> >>> >>>On 5/18/15, 1:51 PM, "Peter Ent" <p...@adobe.com> wrote: >>> >>>>The container appears to have no size. I have it explict (400x400) and >>>>so >>>>it should be a colored rectangle. Without content you get a blank >>>>screen. >>>>Add a label and you get the label inside a 400x400 colored box. >>> >>>Ah, ok. If the container does have size then yes, it should draw >>>something. >>>-Alex >>> >> >
