I’m pretty sure the problem is exactly the opposite.
<body style="width:800px;height:600px">
<div id="outer" style="width:200px;height:100px">
<div id="innner" [width and height infered from the content]>
<span>Some content here</span>
<span>Some content here</span>
<span>Some content here</span>
</div>
</div>
</body>
Inner has the size set by the content and outer needs to then be reset to
accommodate the content. Currently, outer attaches a resize event listener to
inner and when inner is resized i.e. when the layout finishes, it dispatches an
event that causes outer to resize.
Here’s a concrete example:
RoyaleStore has a viewholder Group which has a BasicLayout. The parent of that
is a View which has a VerticalLayout. The size of the viewholder is changed and
sends a sizeChanged event which the View can listen to and run layout (or
something else) as needed (or not). We need to decide whether sizeChanged is
basic enough functionality that it should be dispatched.
Maybe Layout needs to be an IStrand in addition to an IBead and we can have a
size change dispatcher bead which checks for size change after layout and
dispatches the event if necessary. Of course that begs the question: What
decides whether the bead is added to the layouts? How is the viewholder layout
supposed to know whether the View layout cares about resize? Is there some way
for outer layouts to inject beads into inner layouts?
Harbs
> On Mar 26, 2018, at 8:59 PM, Alex Harui <aha...@adobe.com.INVALID> wrote:
>
> Sorry, I knew I forgot to answer something...
>
> Let's make sure we agree on the problem. AIUI, the problem is that if you
> have:
>
> <body style="width:800px;height:600px">
> <div style="width:200px;height:100px" />
> </body>
>
> And the div is 200x100 because it had come custom layout that didn't allow
> for use of just plain percentage or FlexBox, how can the div know if the
> body changes size due to a browser resize? IIRC, there are no change
> events to watch on the parent elements.
>
> So in the original concept of FlexJS/Royale, for PAYG reasons, the layouts
> weren't going to hook up a listener to every child's width/height getters
> "just-in-case" that child changed size and even more important,
> just-in-case that child size change might require another layout. It was
> up to the user to hookup a watcher for the right event on the right
> child/parent. That's Basic and PAYG.
>
> Most folks will hopefully use browser CSS display styles and will
> automatically get reflow. For the hopefully few custom layouts, the user
> can use a LayoutChangeNotifier or something like it to listen for the
> specific thing they care about (resize on the body or load from a child
> image) and trigger a re-layout in the few layouts that need it. In Basic,
> automatically making that happen is not PAYG and thus not a requirement in
> Basic.
>
> The emulation components are probably going to all cache values and
> propagate changes downward just like Flex did.
>
> Again, all we do is encapsulate common patterns. If someone needs custom
> layout logic in a non-Royale JS app, they also probably hook up to the
> resize event on the body.
>
> My 2 cents,
> -Alex
>
>
> On 3/26/18, 10:27 AM, "Harbs" <harbs.li...@gmail.com> wrote:
>
>> I agree with all of this too (mostly).
>>
>> I’m going to to repeat my question for the third time: How can we
>> structure things so layout can know whether their parent layouts are
>> “manual children-sized layouts” which need to have resize events and
>> which have parent layouts which don’t need these events?
>>
>> This is the key point here which we need to find the right answer to. I
>> don’t have the answer to this myself. We need some brainstorming to come
>> up with the right solution to this problem.
>>
>> Harbs
>>
>>> On Mar 26, 2018, at 8:18 PM, Alex Harui <aha...@adobe.com.INVALID>
>>> wrote:
>>>
>>> I feel like several independent factors are being mixed together. I
>>> think
>>> it is better to address them separately.
>>>
>>> Also, IMO, there are two kinds of layout in Royale. One group of
>>> layouts
>>> just lets the browser do the layout, like VerticalLayout,
>>> HorizontalLayout
>>> and the Layouts that use FlexBox. The other group of layouts tries to
>>> run
>>> code to solve layout issues that browsers don't make easy or to emulate
>>> Apache Flex behavior. This is things like VerticalColumnLayout,
>>> VerticalLayoutWithPaddingAndGap, and the FlexibleChild layouts, and some
>>> custom layouts like NumericStepper and the ProductsView layout in
>>> RoyaleStore example.
>>>
>>> When we first started out on FlexJS/Royale six years ago, the only
>>> browser
>>> layouts I knew about were setting the display style to "blocK" or
>>> "inline-block" to get vertical or horizontal layout. So we used it
>>> where
>>> we could and wrote other custom layouts to handle other cases in the
>>> second group. Over time, new display styles have emerged as useful and
>>> stable. Mainly display="flex" a couple of years ago and now/soon
>>> display="grid". Slowly but surely, the browsers are solving the pain
>>> points folks used to workaround.
>>>
>>> I agree with Carlos that we really want the browser to run its layout
>>> code
>>> instead of us running our layout code where possible.
>>
>
