Hi Alex,
I did some research already during last weeks a spend many hours trying
things. Some things I did:
1.- Layouts (for now the 4 horizontal and vertical main layouts) that are
the most used, since are in Cards, HGroup, VGroup,..., loop over the childs
and send "layoutNeeded" event.
(In the second DG TDJ example I put an slider to change the card height,
and the inner DG with height="100%" works as expected, but all thanks to
the "requestAnimationFrame" loop that waits for the height.
For this to work you need to set the parent Card height to some concrete
pixel height. Then DG can be height="100%"
I would want to make this work removing the "requestAnimationFrame" hack.
2.- I think the same could be applied to width="100%" as well based on the
loop hack from 1.- and setting parent Card width to a fixed width.
3.- Maybe nesting some containers with the first to fixed h or w, but the
rest chain of components to 100%, could not work. Still untested.
4.- After the recent email from Piotr in the other Jewel DG thread, I think
we need some convention on how to operate always with the two main events:
* sizeChanged
* layoutNeeded
We should have clear a metodology for all components (Card, HGroup,
DataGrid,...whatever). Should we layouts dispatch layoutNeeded on childs?
or instead "sizeChanged"? or both? I think this is important
If we make some algorithm that make us "industrialize" how we should
implement always the same, I think that would be what all want.
5.- To get proper width and height (real pixels) if we have percentage w o
h: Maybe we should implement some internal code that ensure this at UIBase
(or even up in the hierarchy), or in LayoutBase. At the end we need to ease
those values to the user when "layout()" (in a component's layout ) run.
IOW, if we do at the start of the layout method ´trace(host.width)", we
should get the right value, no matter if they are using pixel or percent
values.
Let me know if you agree with these exposed points.
Thanks
Carlos
El sáb., 14 mar. 2020 a las 17:46, Alex Harui (<[email protected]>)
escribió:
> Hi Carlos,
>
> I've been looking at the number of times the AdvancedDataGrid gets layed
> out in an example from Serkan. That helped me propose this event change.
>
> I see a few other things as well. As I mentioned on some thread recently,
> the view and layout have to consider several scenarios:
>
> 1) sized to content
> 2) sized by parent
>
> And for ADG:
> 3) no data provider
> 4) empty data provider
> 5) data provider set later (usually by server results)
>
> And probably some more. I'm still looking into it. I don't have a
> proposal yet, but my first thought was that the View should be responsible
> for the intelligence that blocks layout passes until the last possible
> event. I think layouts are much more re-usable so they shouldn't carry
> that logic. The View can determine, for example, that the component has a
> percentage height/width and thus know that until there is a sizeChanged
> event, skip all other attempts to layout. But as I mentioned elsewhere,
> that may mean that some of our layouts will need to visit each child. This
> already happens in the MXRoyale set because the MXRoyale code is running
> old Flex layouts in absolute positioning because we want to override
> browser layouts, but isn't true in Basic. Some layouts set display="flex"
> and the browser does the work and there is no loop to visit each child to
> send a sizeChanged event.
>
> Let's get through this event change first, and hopefully I'll have time to
> further optimize ADG, and then I might have time to dig through the Jewel
> DG. But if you have time to do the analysis yourself, I think you want to
> try to understand the "why" for the various layout passes and see if you
> can build in some intelligence around which passes are important in various
> scenarios.
>
> HTH,
> -Alex
>
> On 3/14/20, 3:40 AM, "Carlos Rovira" <[email protected]> wrote:
>
> Hi Alex,
>
> don't know of code that would break, but I think that would be the
> right
> thing to do. So better fix to comply with that change.
>
> What I'm more concern is about getting the pixel width or height when
> sizeChanged or layoutNeeded are thrown from layouts.
> As I stated before in other thread I had some issues, and yesterday
> Piotr
> reported another issue in DataGrid when width="100%" (or any other
> percentage). I could "hack" height using low level js
> requestAnimationFrame, but don't know how to fix percentage width
> problems.
>
> I don't find any way to make calculations in Royale to get the real
> pixel
> width value when a component has width set to some percentage value.
> The
> only way I'm seeing right now is to make some js low level hack with
> calc(%
> -px) in style.width. I think now that we have some infrastructure and
> examples with Cards, HGroups/VGroups, and more, is a good time to have
> some
> easy way to get to the layout() method (or other handler) and get
> directly
> width or height instead of 0 in the case we are using some % value.
>
> Now that I have to work on the fix for Piotr, what do you think about
> to
> take you a look and see that real case problem? Piotr committed
> yesterday
> that DataGrid example to TDJ. If you want we can work over it together
> and
> try what you think it could be a good option.
>
> Would be that possible?
>
> Thanks
>
> Carlos
>
>
>
>
> El sáb., 14 mar. 2020 a las 6:12, Alex Harui (<[email protected]
> >)
> escribió:
>
> > Hi,
> >
> > I am wanting to change the way UIBase setWidthAndHeight dispatches
> its
> > events to cut down on the number of layout passes.
> >
> > Right now, if you change both the width and height of a component,
> you get
> > 3 events (widthChanged, heightChanged, sizeChanged). I want to
> change that
> > so that you only get sizeChanged. This change would cause the
> "meaning" of
> > widthChanged to mean that only the width changed during a resize so
> you can
> > optimize some of the layout code and similar for heightChanged.
> And thus,
> > you will only ever get one event out of setWidthAndHeight, it will
> either
> > be:
> >
> > - "widthChanged" meaning that only the width has changed
> > - "heightChanged" meaning that only the height has changed
> > - "sizeChanged" meaning that both width and height have changed
> >
> > Does anyone know of any code that would break if we made this change?
> > Everywhere I look, code listens to all 3 and does not react
> differently so
> > sometimes lays out 3 times, often once before the height has changed.
> >
> > Thoughts?
> > -Alex
> >
> >
>
> --
> Carlos Rovira
>
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cfa7e4b2f9a89428f2a8008d7c8042840%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637197792495218994&sdata=S05NKAMcGMjcdqZ5eQd81P7Sbb3NJB0TLkrysJS9b%2B8%3D&reserved=0
>
>
>
--
Carlos Rovira
http://about.me/carlosrovira
