First, I like the idea of moving as much into CSS as possible, at least to
the extent we can support in on the SWF side.
Secondly, I think the layouts setting the display makes sense in this
case, based on what Harbs said.
I was thinking of this:
A. UIBase does not set position and display. The values of x, y, width,
height also do not set the corresponding styles (left, top, width, right).
Because we have wrapped elements now and not derived on the SWF side,
setting x, y, width, height do not have to automatically set the
corresponding values on the wrapped element; this will be done by a layout.
B. Container is lightweight and wraps its children so that it can be moved
and displayed as a single unit. Effects would also apply to all items in a
Container.
C. You may size a Container explicitly, but it will clip its children. No
support for scrolling.
D. Containers have layouts and it is the layouts that use the properties
set on the UIBase children. So the BasicLayout would set the children of
the div to display:block, position:absolute and then use the x, y, width,
height properties to set the corresponding styles. This goes against the
above idea of putting everything in CSS, but the point of a layout is to
programmatically size and position items. The VerticalLayout would set the
display:flex of the Container/div and NOT set display/position, etc styles
on its children. Then CSS can be used to set the children's styles; CSS
can also be used to set alignment values on the entire Container.
E. We could have a NoLayout layout that does nothing (the default for a
Container being BasicLayout).
F. Views (every application needs a View) as Containers and in CSS, have
their display:block, position:absolute. This enables the position:absolute
of their children and so forth to have their top, left, bottom, right
styles work correctly.
G. We have ScrollableContainer and ChromeContainer to supply the missing
parts in the PAYG system.
This approach (or something like it) would be in keeping with HTML/CSS
leading the way and then we'd just have to get SWF to follow along. I
don't think that's too much of a problem as long as the SWF version of the
layouts can read the CSS and get the values.
I'm sure there are conditions when a layout isn't used, such as building a
component via its ViewBead, but I think they can be handled by either
introducing the layout concept to those component (e.g. DataGridLayout to
be used by the DataGrid component) or having the ViewBead explicitly
change the values or have them pre-set in defaults.css.
Whew.
‹peter
On 2/22/17, 5:10 PM, "Harbs" <harbs.li...@gmail.com> wrote:
>For that to work, the bead will need to append the class name of the
>component. It cannot be applied to the bead itself.
>
>Harbs
>
>> On Feb 23, 2017, at 12:05 AM, Carlos Rovira
>><carlos.rov...@codeoscopic.com> wrote:
>>
>> Hi Peter,
>>
>> one of the things I'd want to do is remove "styles" in source code and
>>move
>> to css.
>> For example:
>>
>> viewBead.contentView.element.style["display"] = "flex";
>>
>> What do you think about to move this to default.css class, i.e.:
>>
>> HorizontalFlexLayout {
>> display: flex;
>> ...
>> }
>>
>> I think we should move all that kind of code to css so we could tweak
>> (change/modifiy) easily if we need
>>
>> thanks
>>
>>
>> 2017-02-22 23:00 GMT+01:00 Harbs <harbs.li...@gmail.com>:
>>
>>> I totally agree with this.
>>>
>>> There should be a simple Container (with H and V variants) and a
>>>separate
>>> ChromeContainer. The vast majority of Containers do not need the extra
>>>div.
>>>
>>> Moving Panel to Express is an option, but I¹m not sure it¹s necessary.
>>>
>>>> On Feb 22, 2017, at 11:40 PM, Peter Ent <p...@adobe.com> wrote:
>>>>
>>>> I think the Container needs to be redone. I also think it does too
>>>>much
>>> or
>>>> we need a lighter weight component like Group. Container generates two
>>>> <div>s for the HTML side. This is to allow for "chrome" such as
>>>>headers
>>>> and footers. More specifically, it was designed to make it possible to
>>>> write Panel (maybe Panel should be a composite component and moved
>>>>into
>>>> Express).
>>>
>>>
>>>
>>>
>>
>>
>> --
>>
>> 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.
>
