You're welcome to try different approaches to sharing code in the base
classes. Often, though, loops over children need to be inlined not only
for performance reasons (to cut out one function call in the inner loop),
but also for information sharing reasons (local variables accumulating
values would now need to be instance variables). But maybe a more
functional programming style would work here.
OneFlexibleLayout probably shouldn't set align-items or any CSS styles at
all on the JS side. Those values should be set in CSS. If the SWF side
has to run this sort of code, that's the cost of emulating JS in SWF. Or
maybe we need a SWF-side layout base that truly tries to emulate browser
behavior.
Also, for OneFlexible, there is no promise that it uses flex-box under the
hood, it just has to solve what I found to be a hard problem in the
browser (one stretchy thing), so the implementations for JS and SWF can be
widely divergent. If on the other hand we had a FlexBoxContainer, it
would be the job of that code to emulate flex-box on the SWF side and do
almost nothing on the JS side except set flex-box on the div.
My 2 cents,
-Alex
On 7/31/17, 3:42 AM, "Harbs" <harbs.li...@gmail.com> wrote:
>Here’s a dilema I ran into this morning:
>
>The OneFlexibleLayout beads have some code which look like this:
>if (!contentView.element.style["align-items"])
> contentView.element.style["align-items"] = "center”;
>
>What that does, is check if “align-items” is already set and sets it to
>center if not. I’m assuming the reason it sets it to center is because
>the default of flex-box is “stretch” which is not a very good default.
>
>The problem is that center is not necessarily the best default either. I
>would have probably made flex-start the default. In fact, it looks like
>it is the default for swf is left. (flex-start is what I needed in my
>situation.)
>
>I have just committed a change to make the JS consistent with the SWF. It
>now defaults to “flex-start” due to CSS defined on Container. I had to
>add a Container typename for all containers for this to work. I hope this
>is okay. I think it makes sense anyway, because otherwise, there’s no way
>to set custom CSS for all containers. If the style sets “center”, then
>that is honored to center it. The default can be overridden using CSS on
>the JS side, but it will not have an effect on the SWF side.
>
>So far, so good.
>
>Now my question is the follows: It seems kind of random that only
>alignItems:center does anything. I’d think that it should either support
>flex-start, flex-end,center and stretch or not do anything. I’d guess the
>answer is to create OneFlexibleLayoutWithAlignment?
>
>The problem with that is we’d end up writing lots of duplicate code. In
>fact, I went through the different layout classes and the general pattern
>is constant across them:
>
>1. Do something to the parent
>2. Loop through the children, and do something to each one of them.
>
>There are exceptions to this rule (such as the swf side of
>OneFlexibleChild layouts), but the majority of the layouts follow this
>pattern. I was thinking of the following idea to make it easier to
>modularize functionality and avoid code repeat:
>
>Change LayoutBase to the following:
>
>public function layout():Boolean
>{
> var contentView:ILayoutView = layoutView;
> var n:int = contentView.numElements;
> if (n == 0) return false;
> if(!layoutParent())
> return false
>
> for(var i:int=0; i < n; i++) {
> var child:UIBase = contentView.getElementAt(i) as UIBase;
> if(!layoutChild(child))
> return false;
> }
>
> return true;
>}
>protected function layoutParent():Boolean{
> // override in subclass
> return false;
>}
>protected function layoutChild(child:UIBase):Boolean{
> // override in subclass
> return false;
>}
>
>Then in the subclasses, you would only override layout() if it does not
>follow this pattern. When it does, you would just override layoutParent()
>and layoutChild(). That has the following benefits:
>
>1. You do not need to write the loop in every subclass.
>2. Each subclass can use the pieces of the layout that make sense.
>3. If a subclass is just adding additional functionality (such as setting
>the alignment of the children), it only needs to add code for that
>specific functionality without the need to either rewrite the layout
>function twice or make two loops.
>
>Thoughts?
>Harbs
>
