Never mind. I see you answered this question in the other discussion:
<js:style>
<js:SimpleCSSStyles left="10px" right="20px" />
</js:style>
This seems to work well.
I could definitely get used to this.
On Jun 6, 2016, at 11:48 AM, Harbs <[email protected]> wrote:
> If I’m understanding correctly, the constraints are already working as css
> for both browser and Flash. Correct?
>
> What’s the right way to go about declaring these values? Assuming I have some
> markup like this:
> <js:Container>
> <js:beads>
> <js:VerticalLayout />
> </js:beads>
> <js:TextInput text="Type something here" />
> <js:TextButton text="Click Me"/>
> <js:Label id="field" text="Some info"/>
> <js:Label text="Some more info" />
> </js:Container>
>
> and I want my container to be inset from its container by 10 pixels or
> attached to the right side, what’s the best way to declare that?
>
> Right now, I think what FlexJS is missing the most is good documentation and
> IDE autocomplete tools to make the features more discoverable.
>
> On Jun 6, 2016, at 10:55 AM, Alex Harui <[email protected]> wrote:
>
>>
>>
>> On 6/6/16, 6:02 AM, "Harbs" <[email protected]> wrote:
>>
>>> Well, constraint layout is really important. I’m fine with using css for
>>> JS output, but that’s not going to help for a swf first workflow.
>>
>> What do you mean by "constraint layout"? The Spark layout with
>> ConstraintColumns and ConstraintRows? IIRC, it used a lot of compute
>> cycles.
>>
>> CSS is intended to work for SWF-first workflows as well. The goal for the
>> Basic component set is to eventually support all of CSS. The Basic
>> component set is trying to emulate what the browsers do, not the other way
>> around. That way, the output JS is as lightweight and low-overhead as
>> possible. So, if you specify in CSS that left=0, the same thing should
>> happen in the SWF as in the browser.
>>
>>> I’m a bit confused.
>>>
>>> In BasicLayout.layout() there’s the following code:
>>>
>>> var left:Number = ValuesManager.valuesImpl.getValue(child, "left");
>>
>> The ValuesManager abstracts CSS (and other non-CSS values). On the JS
>> side, the code doesn't have to query ValuesManager nearly as often since
>> the browser is just going to deal with it, but when the code we write
>> needs to know what the CSS is that the theme/developer specified, we use
>> ValuesManager to get it. And, like I said, the goal in the code we write
>> is to replicate what the browser will do.
>>
>> HTH,
>> -Alex
>>
>>
>>
>>
>>
>>
>
