In theory, the API for Container should abstract away how many internal pieces there are. It should probably be a div in JS. Adding a ScrollingContainerView should be the PAYG way of turning on overflow:auto.
On the SWF side, the ScrollingContainerView has a lot more work to do. But it should all be under the hood. The coordinate system of children should be the same on both platforms. Essentially, we use PAYG to build up the SWF side to be the equivalent of the HTML div. So borders and backgrounds are not in the API surface. They are under-the-hood. Then, separately, IMO, there is the concept of what I'll call "user chrome". This is visuals in a container that appear to be outside the content area. It could be borders that are not describable in CSS and are thus composited by children of the outer container. It could be a TitleBar/StatusBar/ControlBar/Menu-like row of widgets around some content. I don't know how resize handles are done in JS, but that might be a candidate as well. To me, the question is: what is the coordinate system and numChildren expectations in the HTML/JS world for these kinds of custom containers, and are there pain points related to them that we should solve better in FlexJS? Do people even make re-usable "Panels" in HTML? Where someone supplied a widget with a "title" property and you addChildren to it? Or do folks just grab a plain <div> and build Panels individually by placing a div in there for the title and another for the children? As usual, we want to see what is the optimal way to do this in JS, find the patterns and encapsulate those patterns. My 2 cents, -Alex On 3/7/17, 8:26 AM, "Peter Ent" <p...@adobe.com> wrote: >As I go through FlexJS, I am wondering if we need to continue the idea of >chrome. Chrome is not something built into HTML/CSS/JS, it is artificial. >We use it for the title bar and control bar in a Panel, but a Panel can be >composed of nesting Groups and applying the correct styles. > >In Flex, scroll bars were chrome but they do not have that status in HTML. >In fact, just using overflow:auto will get scrollbars (when needed) on a >Group (aka <div>). To get scrollbars on the SWF side we do need to embed a >scrollable area within an area that will mask the overflowing bits and >provide interactive scroll bars. > >In my mind, Container serves the purpose of allowing those apps that run >on SWF or SWF/JS platforms to have scrollable content. If you were to run >only on JS, then you don't need Container, you can just style the div >provided by Group. But we need to give SWF a hint which can be done by >using Container instead of Group when you suspect the content will need to >be scrolled. The CSS style for Container can have overflow:auto set and >otherwise extend Group for the JS side. The SWF side can nest >DisplayObjectContainers and put scrollbars into the outer container and >use it as a mask. > >Panel can be composed of an outer Group, with a Group for the title bar, a >Container for the content, and another Group for the control bar. If >anyone really needs to have chrome pieces they can do the same thing. > >What do you think? Should Container continue to support chrome (aka, >components implementing IChrome interface) or should it just be for >scrollable content? > >Thanks, >Peter > >On 3/7/17, 10:31 AM, "Peter Ent" <p...@adobe.com> wrote: > >>Thanks for the feedback! >> >>As I go through the examples, I see that we (mostly me) created a number >>of nested elements, such as a <div><button></div> for an item renderer. >>That makes it more difficult to lay out since the content of the div is >>not always set to fill the div's space. I think each of the components >>and >>renderers need to be examined and updated. >> >>—peter >> >>On 3/7/17, 10:04 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira" >><carlos.rov...@gmail.com on behalf of carlos.rov...@codeoscopic.com> >>wrote: >> >>>Hi Peter, I think this awesome. get rid of the hardcoded styles in >>>component classes is such important thing and first point not only in >>>your >>>effort of create a good layout strategy, but an important previous step >>>if >>>we want to implement theming in FlexJS. >>> >>>Great! :D >>> >>>Carlos >>> >>> >>>2017-03-07 14:23 GMT+01:00 Peter Ent <p...@adobe.com>: >>> >>>> This is the theory, yes. A way to do your own thing using AS and MXML >>>>to >>>> construct the app which then generates the right amount of HTML >>>>structure, >>>> making it easier to style. Or use pre-built constructions and layouts >>>>as >>>> templates that also generate the right amount of HTML structure. >>>> >>>> I'm thinking that Panel would be a good case for a composite component >>>>and >>>> maybe even move it into Express. In theory, you can compose a Panel >>>>from: >>>> >>>> <Group> with VerticalFlexLayout >>>> <Group> with Horizontal Flex Layout for the Title Bar >>>> <Container> to provide scrollable area >>>> <Group> with Horizontal Flex Layout for the Control Bar >>>> </Group> >>>> >>>> We'll see how this goes. >>>> ‹peter >>>> >>>> On 3/6/17, 5:02 PM, "Alex Harui" <aha...@adobe.com> wrote: >>>> >>>> > >>>> > >>>> >On 3/6/17, 1:26 PM, "piotrz" <piotrzarzyck...@gmail.com> wrote: >>>> > >>>> >>Hi Peter, >>>> >> >>>> >>It looks awesome. Cause if I'm enough skilled in CSS I can do >>>>whatever >>>> >>layout I want and I don't need to know any other one. - In theory. >>>>:) >>>> > >>>> >True, but like with everything else in FlexJS, we are trying to >>>> >encapsulate common patterns and make them easier to use. >>>> > >>>> >So for example if you have 3 children in a container and want to make >>>>the >>>> >first one stretchy, you might have to write: >>>> > >>>> ><Group style="display:flex" /> >>>> > <Label style="flex-grow: 2" /> >>>> > <Button style="flex-grow: 1" /> >>>> > <Button style="flex-grow: 1" /> >>>> ></Group> >>>> > >>>> >Whereas with a layout you could write: >>>> ><Group> >>>> > <beads> >>>> > <FirstFlexibleChildLayout /> >>>> > </beads> >>>> ></Group> >>>> > >>>> >That way you don't have to remember the names of the styles or look >>>>up >>>>how >>>> >to do it. >>>> > >>>> >Hopefully our Layouts will essentially do just that once Peter's done >>>>with >>>> >this refactor. >>>> > >>>> >Of course, I could be wrong... >>>> >-Alex >>>> > >>>> >>>> >>> >>> >>>-- >>> >>>Carlos Rovira >>>Director General >>>M: +34 607 22 60 05 >>>http://www.codeoscopic.com >>>http://www.avant2.es >>> >>>Este mensaje se dirige exclusivamente a su destinatario y puede contener >>>información privilegiada o confidencial. Si ha recibido este mensaje por >>>error, le rogamos que nos lo comunique inmediatamente por esta misma vía >>>y >>>proceda a su destrucción. >>> >>>De la vigente Ley Orgánica de Protección de Datos (15/1999), le >>>comunicamos >>>que sus datos forman parte de un fichero cuyo responsable es CODEOSCOPIC >>>S.A. La finalidad de dicho tratamiento es facilitar la prestación del >>>servicio o información solicitados, teniendo usted derecho de acceso, >>>rectificación, cancelación y oposición de sus datos dirigiéndose a >>>nuestras >>>oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la documentación >>>necesaria. >> >
