A final note.

In Jewel most of the layouts are based on flex-box, so you don't need
anything (as you already saw in TDJ).

Tile layouts need to be aware of browser sizing, since they need to update
margins and gaps on child elements depending on width or height container.
I didn't find a way to do tile layout just using flexbox (not adding some
as3/javascript code), and think it can't be done (if someone knows a way,
please let me know).

DataGridLayout is another layout that needs a mix of css flexbox and code.

We probably will need to add grid css layout at some point, and that could
make tile layout easier and just depend on browser.
Until now I didn't want to add flexbox since it will mean not support IE11.
But recently I saw there's some grid css polyfills out there.

Maybe it wouldn't support all grid spec, but could be just what we need
without left IE11 support.





El lun., 8 jun. 2020 a las 10:24, Carlos Rovira (<[email protected]>)
escribió:

> Hi,
>
> continuing with sizing and layout. Just added "BrowserResizeListener" and
> renamed the old one to "BrowserResizeApplicationListener" to avoid
> confusion, since the latter can be used only at app level.
>
> About how to deal with browser resizing and make your inner components
> respond accordingly. I found basically three ways to deal with
> child layouts when you really needed and avoid performance issues running
> code that you really not need.
>
> 1.- The best way is to add a "BrowserResizeListener" at component level,
> so the rest of your app just uses the browser layout as usual. This will be
> the best for the performance of your application since we are just running
> code in the part we need.
>
> 2.- For layouts more in the "Flex style" where there's a chain of
> parent-child layout calls you can:
>
>    - Add "BrowserResizeApplicationListener" art app level
>    - Add width/height 100% to View level (notice that in a normal jewel
>    app we don't set up this to allow natural browser resizing)
>    - Then add "LayoutChildren" bead to any container/component in the
>    tree that need to signal a change in size and need to refresh layout.
>    (notice that this could mean to add this bead to many components down the
>    hierarchy, so this could be a bit cumbersome)
>
> This way seems to me not ideal, since it can inherit all Flex performance
> problems since we'll be running lots of layout code that could not be
> needed at all, but it will depend on your app. I recommend avoiding this
> method if possible.
>
> 3.- (Basically a MIX of 1 & 2). You choose a part of the mxml tree where
> you need to manage sizing and choose when you want to notify childrens:
>
>    - Add "BrowserResizeListener" to the component/container you want
>    (that could have more subcomponents or containers in its subtree)
>    - Add "LayoutChildren" too in that component/container
>    - Add "LayoutChildren" to any component/container you need until you
>    reach the inner component that need to relayout to show in the right way.
>    This could be just few sub components in that tree, or all... Just notice
>    that you need "LayoutChildren" from the where "BrowserResizeListener" is
>    added down to the component that need to react to browser size changes.
>
> I tried three ways, but I think 1 is of course more simple to implement
> and more performant.
>
> I think this way we have all sizing in Jewel under control. Let me know if
> you find any issue we need to take into account.
>
> HTH
>
> Carlos
>
>
> El dom., 7 jun. 2020 a las 21:52, Carlos Rovira (<[email protected]>)
> escribió:
>
>> Hi,
>>
>> I added a new bead "LayoutChildren" that can be added to a jewel component
>> if StyledLayoutBase detect this bead it will signal a "sizeChanged" for
>> childs when needed.
>>
>> It uses the same technique as the itemrenderer initializers of composing
>> the bead and in that case
>> use its code. If no bead is added, no code is run.
>>
>> Until now Jewel was adding a loop in all layouts to manage child
>> elements, but since we use browser layouts in many cases
>> this loop is not needed and could cause a performance problem.
>>
>> So from now on, if you need that extra processing just add this bead to
>> the component.
>>
>> A case of the use is in the recent change in TDJ in the second card of
>> DataGridPlayGround
>>
>> Best
>>
>>
>> --
>> Carlos Rovira
>> http://about.me/carlosrovira
>>
>>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>
>

-- 
Carlos Rovira
http://about.me/carlosrovira

Reply via email to